El día que el error dejó de ser del equipo...
ERP para PYME
Hay un punto en el crecimiento donde el problema deja de ser esfuerzo y pasa a ser diseño. No ocurre de golpe, sino de forma gradual. La empresa sigue vendiendo, el equipo responde y los resultados llegan, pero el cansancio empieza a acumularse en lugares que antes no dolían. Desde fuera todo parece funcionar. Desde dentro, cada día cuesta un poco más.
Hoy visité a una distribuidora de abarrotes que está justo en ese punto. Treinta personas, ventas activas, un almacén bajo presión diaria y administración tratando de que el mes cierre sin sobresaltos. El dueño ya no alcanza a estar en todo y la operación depende cada vez más de que las cosas “salgan” como sea.
En una reunión corta, alguien dijo lo que todos pensaban pero nadie había dicho en voz alta: “Siempre acabamos corrigiendo pedidos”. No hubo acusaciones ni reproches. Solo un silencio denso. Nadie señalaba a nadie, y aun así todos se sentían parte del problema.
Cuando el error se repite, deja de ser humano
El dueño podría haber hecho lo habitual. Pedir más cuidado, exigir orden o recordar objetivos. En lugar de eso, dijo algo distinto: “Si esto pasa todos los días, no es porque ustedes fallen. Es porque la empresa les deja fallar”. No fue un discurso motivacional. Fue una frase incómoda que obligó a dejar de mirar personas y empezar a mirar el sistema.
A partir de ahí, la conversación cambió. Ventas explicó cómo cerraba pedidos bajo presión, apoyándose más en memoria que en un CRM que no reflejaba la realidad. Almacén habló de su libreta y de por qué no confiaba del todo en lo que llegaba de otras áreas. Administración explicó por qué prefería corregir después en silencio antes que frenar la operación y generar conflicto.
Nadie estaba actuando con mala intención. Cada área había encontrado su forma de sobrevivir dentro de un diseño incompleto. El problema no era quién se equivocaba, sino que el pedido nunca tenía una forma clara desde el inicio. Existía repartido entre mensajes, recuerdos y correcciones posteriores.
Asumir responsabilidad estructural cambia la operación
Lo que este jefe hizo bien no fue inspirar con palabras, sino asumir responsabilidad estructural. Entendió que mientras el pedido no naciera definido dentro de una arquitectura común, la operación seguiría dependiendo de personas y buena voluntad. Y eso, sostenido en el tiempo, quema a cualquiera.
La decisión fue sencilla, pero firme. Definir cómo nace un pedido y no permitir que avance si no está completo. No para controlar más, sino para dejar de poner al equipo en situaciones imposibles y recuperar eficiencia operativa sin exigir heroicidades diarias.
Las semanas siguientes no fueron mágicas. Hubo fricción y resistencia. Pero también pasó algo importante. La gente dejó de sentirse culpable por problemas que no podía evitar. Empezaron a trabajar con menos tensión porque el ERP dejó de ser un registro tardío y pasó a marcar el flujo real del trabajo, con trazabilidad clara desde el inicio.
A veces ser buen jefe no es inspirar. Es aceptar que si tu gente se equivoca todos los días en el mismo punto, el error no es de ellos. Es del diseño que tú permitiste y de la falta de alineación tecnología–negocio que se fue normalizando con el tiempo.
Si esto te hizo pensar en tu propia operación, cuéntame: ¿en qué parte del flujo sientes que tu equipo está pagando el precio de un mal diseño?