Hay un momento exacto en el que un proyecto de transformación fracasa. Suele ser el martes de la semana siguiente al lanzamiento. Nadie lo documenta porque nadie quiere firmarlo.
Es el martes en el que alguien abre el nuevo sistema, tarda tres veces más de lo habitual en hacer lo que siempre ha hecho, suspira, menea la cabeza, cierra la ventana y abre el Excel de toda la vida. Sin drama. Sin declaración de intenciones. Sin correo al jefe explicando nada. Solo un hábito que gana a una metodología, porque el hábito no necesita manual.
A partir de ahí, el proceso perfecto empieza su declive silencioso. Y nadie lo ve, porque todos están ocupados preparando el informe de cierre del proyecto.
El software no tiene la culpa. Nunca la tiene. Una herramienta no es buena ni mala en abstracto: depende de cómo se despliega, de quién la usa y, sobre todo, de si alguien se ha ocupado de que la persona que va a usarla entienda por qué debería querer hacerlo. Eso no lo resuelve ninguna licencia, por cara que sea.
El consuelo de los diagramas
En casi todos los ámbitos de gestión tendemos a enamorarnos de la estructura. Razonamos que si el diagrama es lógico, la gente lo seguirá. Es una creencia cómoda porque nos permite centrarnos en lo que se puede dibujar y medir, y dejar fuera lo que no: la resistencia, el escepticismo, el cansancio acumulado de quien ya vivió tres «transformaciones» anteriores y recuerda perfectamente cómo terminaron.
El cambio no es un interruptor. Es una transición psicológica. Tratarla como un hito de proyecto —»formación completada», «cambio entregado»— es la forma más eficiente de garantizar el fracaso.
Existe un modelo que lo describe con precisión: ADKAR. No es un mueble escandinavo ni un acrónimo inventado por un departamento de RRHH con demasiado tiempo libre. Son las siglas en inglés de un mapa de cinco etapas que explica por qué la gente no adopta los cambios aunque haya asistido a la formación, firmado el acuse de recibo y sonreído en la foto del lanzamiento. Conciencia del problema, deseo de cambiar, conocimiento de cómo hacerlo, capacidad para ejecutarlo y refuerzo para que no se olvide. En ese orden. Sin atajos.
De las cinco etapas del modelo, hay tres que ningún proyecto presupuesta: el Deseo, la Capacidad y el Refuerzo.
La etapa más ignorada es el Deseo. Y es la más importante.
La mayoría de los proyectos de transformación tienen un business case impecable para la dirección y ningún argumento para el que va a trabajar con el nuevo sistema a las ocho de la mañana. Si el cambio beneficia a la cuenta de resultados pero añade tres pasos al proceso diario de quien ejecuta, su predisposición a colaborar será tibia. Puede que incluso hostil, con la discreción característica de quien ha aprendido que la resistencia abierta tiene consecuencias y la pasiva, no.
La Capacidad es otra trampa. Saber cómo se hace algo no es lo mismo que poder hacerlo bajo la presión del día a día. Una formación de dos horas puede transferir conocimiento; no puede cambiar hábitos consolidados durante años. Y los hábitos, ante el estrés, siempre ganan.
El Refuerzo es lo que se elimina primero cuando aprieta el presupuesto. El equipo de implementación desaparece en cuanto se entrega el proyecto, y sin indicadores que premien el nuevo comportamiento, la entropía hace su trabajo. La gente vuelve a lo conocido, no porque el cambio fuera malo, sino porque nadie se ocupó de que seguir el camino nuevo fuera más fácil que volver al viejo.
Lo que sí funciona, aunque no quepa en un Gantt
Si quieres que tu próximo proceso sobreviva más allá del PowerPoint de presentación:
- Vende el problema antes de vender la solución. Antes de enseñar las pantallas nuevas, dedica tiempo a que el equipo experimente en carne propia lo costoso que es el proceso actual. Sin diagnóstico compartido no hay motivación real. Si no ven el incendio, tu extintor les parecerá un obstáculo molesto.
- Involucra a los que sufren el problema en el diseño de la solución. No como gesto de participación democrática ni para que nadie se sienta excluido. Sino porque son los únicos que saben exactamente dónde duele y por qué los atajos que usa todo el mundo tienen sentido. Un proceso diseñado sin ellos tiene todas las papeletas para ser técnicamente correcto y operativamente ignorado.
- Diseña para quien trabaja, no para quien dirige. Antes de validar cualquier proceso, una sola pregunta: ¿esto le ahorra tiempo al operativo o solo le da mejores gráficos al director? Si es lo segundo, la resistencia ya está en camino, aunque todavía no la veas.
- No declares la victoria demasiado pronto. El brindis es el principio de la parte difícil, no el final. Vuelve a los 30, 60 y 90 días — no a comprobar que todo va bien, sino a eliminar los incentivos que hacen que trabajar a la antigua siga siendo la opción más cómoda para quien ejecuta.
Un proceso en un PowerPoint es exactamente eso: un PowerPoint. El valor real de la gestión no está en diseñar sistemas perfectos, sino en conseguir que personas imperfectas los adopten y no los abandonen a la primera presión. Para eso hacen falta menos metodologías y bastante más comprensión de cómo funciona la gente cuando nadie la está mirando.