El viernes cerraron el taller. Dos horas, diapositivas, ejercicios prácticos. El equipo asintió. Algunos tomaron notas. El facilitador salió convencido de que algo había cambiado.
El lunes siguiente, la operación funcionaba exactamente igual que antes.
Si reconoces esa escena, no estás solo. Es probablemente la experiencia más común y más frustrante en la gestión de operaciones logísticas. Y la explicación que más se repite es siempre la misma: resistencia al cambio.
Esa explicación es cómoda. También es incorrecta.
Cuando una mejora operacional no se sostiene después de la capacitación, el problema rara vez es la gente. El problema es que nadie diseñó la transición. Y eso es una falla de implementación, no de actitud.
El diagnóstico que nadie quiere hacer
La resistencia al cambio existe. Pero en operaciones logísticas, la mayor parte de lo que se llama resistencia no es resistencia: es inercia de sistema.
La diferencia importa. La resistencia implica que la persona no quiere cambiar. La inercia de sistema implica que el entorno en el que trabaja esa persona (sus métricas, sus rutinas, sus herramientas, la presión del turno) sigue recompensando el comportamiento anterior. Aunque la persona quiera cambiar, el sistema la devuelve al punto de partida.
Piénsalo así: entrenas a un conductor para que registre los tiempos de carga en la aplicación en lugar del cuaderno. El lunes llega con tres unidades atrasadas, el supervisor le pregunta el estado cada diez minutos, y registrar en la app toma el doble de tiempo que anotar en el cuaderno. ¿Qué hace el conductor? Lo que le permite sobrevivir el turno.
No es resistencia. Es adaptación racional a un entorno que no cambió.
Lo que la aviación aprendió sobre cambiar procedimientos
En aviación, los procedimientos de vuelo cambian con frecuencia. Nuevas regulaciones, actualizaciones de fabricante, lecciones de incidentes, revisiones de rutas. La industria aprendió hace décadas que la manera en que se implementa un cambio de procedimiento determina si ese cambio realmente ocurre o si solo existe en el papel.
Cuando un procedimiento cambia en aviación, no se publica un memorando y se espera que la tripulación lo adopte. Existe un protocolo formal: el cambio se anuncia con anticipación, se establece una fecha de vigencia, se realiza un briefing estructurado que explica el porqué del cambio, no solo el qué, se evalúa la comprensión antes de que el piloto vuele con el nuevo procedimiento, y el procedimiento anterior queda explícitamente retirado. No deprecado. Retirado. La razón es simple: si el procedimiento viejo sigue disponible como opción, en un momento de estrés el piloto va a recurrir a lo conocido.
Compara eso con cómo se implementan la mayoría de cambios en operaciones logísticas:
| Elemento | Aviación | Logística típica |
|---|---|---|
| Anuncio del cambio | Anticipado, con fecha de vigencia clara | Reunión o correo, sin fecha de corte |
| Explicación del porqué | Obligatoria en el briefing | Opcional, frecuentemente omitida |
| Evaluación de comprensión | Formal, antes de aplicar el cambio | Asumida tras la capacitación |
| Período de transición | Definido, con soporte activo | Inmediato, sin acompañamiento |
| Retiro del procedimiento anterior | Explícito y documentado | Rara vez formalizado |
| Seguimiento post-implementación | Verificación en vuelo real | Reunión de seguimiento (si ocurre) |
La industria aérea no desarrolló ese protocolo por burocracia. Lo desarrolló porque los accidentes le enseñaron que la diferencia entre "saber el nuevo procedimiento" y "ejecutar el nuevo procedimiento bajo presión" no se cierra con una capacitación. Se cierra con una transición bien diseñada.
Los tres momentos donde muere un cambio operacional
Después de analizar implementaciones fallidas en distintas operaciones, el patrón se repite. Los cambios no mueren en un solo punto: mueren en secuencia, en tres momentos predecibles.
Momento 1: el vacío entre el taller y el turno
La capacitación termina. El equipo vuelve al turno. Y en ese momento, nadie está ahí para acompañar la primera vez que alguien tiene que ejecutar el nuevo proceso en condiciones reales: con presión, con tiempo limitado y con excepciones que el taller no cubrió.
Ese primer día de aplicación real es el momento más crítico de cualquier implementación. Si el equipo lo atraviesa solo y el nuevo proceso genera más fricción que el anterior, la conclusión es obvia: el proceso viejo funcionaba mejor. No porque sea verdad, sino porque la curva de aprendizaje no tuvo soporte.
Momento 2: la primera excepción sin protocolo
Todo proceso nuevo fue diseñado para el escenario estándar. La primera vez que aparece una excepción (un proveedor que no envió la documentación, un sistema que falló, una urgencia de último minuto), el equipo no sabe cómo manejarla con el proceso nuevo.
Y en ese momento recurre a lo que sabe: el proceso anterior. Una vez. Luego dos veces. Y en tres semanas, el proceso nuevo solo existe para los casos fáciles, que son los que menos lo necesitaban.
Momento 3: el entorno que no cambió
Este es el más silencioso y el más definitivo. El proceso cambió. Las métricas no. Los incentivos no. La forma en que el supervisor evalúa el desempeño no. El sistema de información que el equipo usa tampoco.
Si el indicador que se mide sigue siendo el mismo de antes, y el proceso nuevo no mejora ese indicador en el corto plazo (aunque lo mejore en el mediano), el equipo racionaliza el regreso al proceso anterior como la decisión correcta. Y tiene razón: dentro del sistema de incentivos que existe, lo es.
El protocolo de transición operacional
El problema no es la capacitación. Es lo que ocurre después. La transición es la etapa que casi ninguna operación diseña, y es exactamente donde se decide si el cambio se instala o muere.
Basado en lo que funciona en implementaciones reales, y en los principios de gestión del cambio de procedimientos que la aviación formalizó décadas atrás, hay cinco elementos que no pueden faltar en cualquier transición operacional:
1. Fecha de corte, no fecha de inicio
La mayoría de implementaciones anuncian cuándo empieza el proceso nuevo. Pocas anuncian cuándo termina el proceso anterior.
La diferencia es enorme. Si el proceso viejo sigue siendo una opción (aunque no oficial), el equipo lo va a usar en los momentos de mayor presión. Definir una fecha de corte real, después de la cual el proceso anterior ya no está disponible, elimina la ambigüedad y obliga a que la transición sea real.
2. Acompañamiento en los primeros tres turnos
Los primeros tres turnos de aplicación del proceso nuevo son los más críticos. No los primeros tres días: los primeros tres ciclos completos de operación. En ese período tiene que haber alguien (un líder, un par entrenado, el propio implementador) disponible para resolver excepciones en tiempo real.
Ese acompañamiento no es supervisión: es soporte técnico. La diferencia está en el tono. El objetivo no es verificar que se cumpla: es asegurar que cuando aparezca la primera fricción, haya alguien que ayude a resolverla dentro del nuevo proceso, no fuera de él.
3. Protocolo para excepciones desde el día uno
Todo proceso nuevo va a encontrar situaciones que no estaban en el diseño original. Si no existe un protocolo para manejar esas excepciones, el equipo va a inventar uno. Y ese protocolo improvisado va a ser el proceso anterior.
Antes de lanzar cualquier cambio, hay que definir explícitamente qué hace el equipo cuando el proceso nuevo no cubre un caso. No "escalen al supervisor": eso es diferir el problema. Hay que definir la regla de excepción y entrenarla tan formalmente como el proceso principal.
4. Una métrica que cambie con el proceso
Si el cambio de proceso no va acompañado de un cambio en cómo se mide el desempeño, el equipo va a optimizar para la métrica vieja con el proceso nuevo, y va a fracasar en ambas cosas.
No se trata de agregar un indicador nuevo. Se trata de identificar cuál de las métricas actuales se ve directamente afectada por el nuevo proceso y hacerla visible durante la transición. Esa visibilidad crea el argumento operacional que sostiene el cambio cuando la presión del turno lo pone en duda.
5. Verificación a los 21 días
En aviación existe el concepto de line check: una verificación formal de que el piloto aplica correctamente un procedimiento en condiciones reales de vuelo, no en simulador. No es un examen: es una confirmación de que la transición ocurrió.
En operaciones logísticas el equivalente es una revisión estructurada a los 21 días de implementación. No para evaluar si "les fue bien", sino para diagnosticar específicamente en qué situaciones el proceso nuevo no se está aplicando y por qué. Esa información es la que permite ajustar la implementación antes de que el retroceso se vuelva permanente.
Por dónde empezar con tu próximo cambio
La próxima vez que vayas a implementar una mejora operacional, antes de preparar la capacitación, responde estas cinco preguntas:
- ¿Cuándo exactamente deja de ser válido el proceso anterior? Si no tienes una fecha de corte, no tienes un cambio: tienes una opción adicional.
- ¿Quién va a estar en el piso durante los primeros tres turnos? Si la respuesta es "nadie", ya sabes qué va a pasar en el cuarto turno.
- ¿Qué hace el equipo cuando el proceso nuevo no cubre un caso? Si no tienes una respuesta documentada, la van a improvisar con el proceso viejo.
- ¿Qué métrica visible va a mejorar con este cambio en las primeras dos semanas? Si la mejora tarda tres meses en verse, necesitas un indicador intermedio que muestre trayectoria antes de que el equipo pierda la confianza.
- ¿Cuándo vas a verificar que el cambio realmente ocurrió? No cuándo vas a hacer el seguimiento de resultados, sino cuándo vas a confirmar que el comportamiento cambió.
Si puedes responder esas cinco preguntas antes de lanzar la implementación, tienes un protocolo de transición. Si no puedes, tienes una capacitación. Y la diferencia entre las dos es exactamente la distancia entre el viernes del taller y el lunes de la operación real.
El cambio no ocurre en el taller
La capacitación le da al equipo el conocimiento del proceso nuevo. La transición le da al equipo la experiencia de ejecutarlo bajo presión, con excepciones reales, en un entorno que empezó a recompensar el comportamiento nuevo.
Son dos cosas distintas. Y la segunda es la que la mayoría de operaciones nunca diseña.
La próxima vez que una mejora operacional no se sostenga, antes de concluir que el equipo tiene resistencia al cambio, pregúntate qué pasó entre el viernes del taller y el lunes siguiente. Qué soporte había disponible. Qué métricas cambiaron. Qué pasaba cuando alguien encontraba una excepción que el proceso nuevo no cubría.
La respuesta va a revelar si el problema fue la gente o el diseño de la transición.
Casi siempre es el diseño.
¿Cuál fue la última mejora operacional que implementaste y no se sostuvo? ¿En cuál de los tres momentos murió?