ERP después, una secuencia que muchas empresas invierten
Hay una pregunta que se repite cada vez que una operación empieza a desordenarse: ¿hace falta más sistema o hacen falta mejores decisiones? Yo me he encontrado muchas veces con empresas donde esa pregunta se contesta al revés, y bastante seguido. Compran software para intentar corregir una operación que todavía no sabe gobernarse. Y entonces el ERP, que supuestamente venía a poner orden, termina acelerando la confusión.
Un ERP no crea criterio. Solo convierte en proceso el criterio que ya existe, para bien o para mal. Cuando el modelo de gobierno está flojo y las prioridades cambian por miedo, urgencia o por el impulso del momento, el sistema no arregla nada. Lo que hace es volver más rápido el retrabajo, más visible la incoherencia y más caro el error.
Ese patrón me lo encontré en una manufacturera e instaladora que traía varios millones de pesos de deuda y, para acabarla, no tenía visibilidad real a dos o tres meses. Lo que parecía un problema de software en realidad venía de algo más básico: no había una forma estable de cerrar decisiones. Las prioridades cambiaban todo el tiempo, la caja metía presión y la autoridad real estaba concentrada en una sola persona. Meter tecnología antes de ordenar eso es, básicamente, codificar la inestabilidad.
Muchas organizaciones subestiman el costo oculto de invertir esa secuencia. No solo se desperdicia la implementación, también crece la resistencia interna. Y aquí viene la parte incómoda: cuando la empresa vive en modo supervivencia, la aparente adaptación no significa alineación. La gente ejecuta para evitar conflicto, no porque esté sosteniendo un proceso. Y esa diferencia pesa muchísimo cuando intentas introducir un ERP.
Antes de automatizar, hay que estabilizar quién decide, cómo se revisan los cambios y qué procesos están realmente bajo control. Si eso no existe, el sistema queda expuesto a oscilaciones permanentes. Cualquier diseño técnico, con más o menos trazabilidad, con rollback o sin él, termina funcionando como una defensa improvisada frente a un problema de gobierno.
En este caso, la situación empezó a cambiar cuando se protegió la ejecución con una capa paralela de control y se empezó a medir el costo real del caos, desde las horas perdidas hasta los retrabajos, la rotación y el burnout. Con esa base, la conversación dejó de ser opinativa. Cuando la decisión se estabilizó, el proyecto avanzó más en una semana que en meses previos. No fue el software lo que cambió. Fue la secuencia de mando que por fin pudo sostenerlo.
La lección para cualquier CTO es bastante simple, aunque no siempre cómoda. Si la empresa no puede fijar criterios, el ERP no va a resolverlo. Primero gobierno, luego procesos y después automatización. Todo lo demás solo acelera un sistema que todavía no sabe a dónde va.
