ADKAR es el modelo más usado en gestión del cambio. También es el más mal aplicado. Si lideras una transformación tecnológica, esto te interesa.
Si trabajas en transformaciones organizacionales, conoces ADKAR. Awareness, Desire, Knowledge, Ability, Reinforcement. Cinco letras que resumen el proceso por el cual una persona adopta un cambio.
Es un modelo elegante. Bien fundamentado. Ampliamente certificado pero insuficiente para la complejidad de una transformación tecnológica moderna.
Eso no es una crítica a Prosci ni a sus investigadores. Es una observación sobre cómo se usa ADKAR en la práctica, y por qué esa aplicación falla sistemáticamente cuando el cambio involucra sistemas enterprise, múltiples stakeholders, rediseño de procesos y presión de entrega simultánea.
El problema no es el modelo. Es el uso.
ADKAR fue diseñado como un modelo de cambio individual. Describe el viaje de una persona a través del cambio. Es poderoso para diagnóstico, para conversaciones de coaching con empleados, para entender por qué alguien resiste.
Lo que no hace, y lo que muchos Change Managers asumen que sí hace, es explicarte cómo diseñar la arquitectura de cambio de una transformación completa. No te dice cómo integrar el plan de Change Management con el cronograma del proyecto tecnológico. No resuelve la dinámica de poder entre el sponsor ejecutivo, el equipo de TI y los usuarios clave. No te explica qué hacer cuando el go-live se adelanta tres semanas y tu estrategia de comunicación todavía no está lista.
Para eso, ADKAR necesita compañía.
Lo que falla en la práctica
En transformaciones tecnológicas complejas como implementaciones de ERP, CRM, HCM, plataformas de datos, los planes de Change Management; y más aún si sumamos múltiples unidades de negocio y múltiples países, fracasan por razones que ADKAR no anticipa:
1. El modelo se aplica de forma lineal en entornos no lineales. ADKAR asume una secuencia: primero construyes Awareness, luego Desire, luego Knowledge. Pero en una implementación ágil con sprints de dos semanas, los usuarios reciben funcionalidades nuevas antes de que hayas completado la fase de Awareness del módulo anterior. El modelo no está diseñado para esa cadencia.
2. Ignora la dinámica sistémica de la organización. Una transformación no afecta a personas aisladas. Afecta roles, procesos, estructuras de poder, incentivos y relaciones entre departamentos. ADKAR no incluye herramientas para modelar esas interdependencias. Si no entiendes cómo el cambio en el área de logística impacta al equipo de finanzas, tu plan de Change Management tiene puntos ciegos peligrosos.
3. La resistencia tiene causas que ADKAR no diagnostica bien. ADKAR identifica resistencia, fundamentalmente como falta de Desire. Pero la resistencia en contextos tecnológicos puede originarse en miedo a perder poder, en falta de psicología de seguridad para reportar errores del sistema, en incentivos formales que premian el comportamiento antiguo. Esas causas requieren marcos distintos: diseño conductual, teoría de nudges, análisis de redes organizacionales.
4. No integra métricas de adopción con métricas del proyecto. La mayoría de planes de Change Management basados exclusivamente en ADKAR producen reportes de actividades: cuántas comunicaciones se enviaron, cuántas capacitaciones se realizaron; pero no conectan esas actividades con indicadores de adopción real: uso del sistema, calidad del dato ingresado, reducción de workarounds, tiempo de transacción post go-live.
Lo que un Change Manager avanzado necesita saber
Los marcos clásicos (ADKAR, Kotter, Lewin) siguen siendo válidos como fundamentos. El error es usarlos como si fueran suficientes por sí solos.
Las transformaciones tecnológicas complejas requieren una capa adicional de competencias:
· Systems Thinking para entender las interdependencias organizacionales antes de intervenir
· Diseño conductual y Nudge Theory para modificar comportamientos sin depender solo de la comunicación
· People Analytics para medir adopción con datos reales de uso, no con encuestas de satisfacción
· Process Mining para identificar dónde los procesos diseñados divergen de los procesos ejecutados — la brecha de adopción invisible
· Integración del roadmap de Change Management con el roadmap tecnológico, no como actividades paralelas, sino como una sola arquitectura de transformación
Esta no es teoría académica. Es la diferencia entre un plan de Change Management que se archiva después del go-live y uno que genera ROI medible.
La pregunta que vale hacerse
Si estás liderando una transformación tecnológica hoy, pregúntate: ¿tu plan de Change Management está diseñado para el proceso de adopción individual, o para la complejidad sistémica de la organización completa?
Si la respuesta es lo primero, tienes un buen punto de partida. Pero probablemente no es suficiente.
El programa Change Management para Transformaciones Tecnológicas y Organizacionales de ISFIS fue diseñado precisamente para cerrar esa brecha, integrando los marcos clásicos con las herramientas avanzadas que las transformaciones modernas exigen.
6 sesiones. 18 horas. Para líderes que ya conocen ADKAR y quieren saber qué va después.
