Los proyectos de cambio no fracasan por el software. Fracasan porque el cerebro procesa el cambio como una amenaza, porque la resistencia es social antes que técnica, porque el éxito pasado ancla a la organización, porque se apela a la lealtad en vez de al interés de cada quien, y porque se trata a los críticos como enemigos en lugar de como la mejor fuente de información disponible.
1. Nadie debate el cambio: lo interpreta como amenaza
El primer error es suponer que la gente evalúa una iniciativa de cambio de forma racional, comparando ventajas y desventajas. No es lo que ocurre. La reacción inicial es de amenaza, y lo que está en juego no es la eficiencia de la empresa sino la sensación de control sobre el propio trabajo.
Alguien que lleva ocho años dominando un proceso en Excel no está defendiendo Excel. Está defendiendo ser la persona que sabe cómo se hace. Presentarle una comparativa de funcionalidades no resuelve nada, porque no está discutiendo funcionalidades.
2. La resistencia es social, no técnica
El segundo supuesto erróneo es que la gente se resiste a la tecnología nueva. Rara vez es así. Se resiste a lo que el cambio hace con las relaciones dentro del grupo: quién depende de quién, quién tiene la información, quién queda expuesto cuando el sistema muestra lo que antes no se veía.
Por eso una capacitación impecable puede no mover la aguja. El problema no estaba en que no supieran usarlo.
3. El éxito pasado es el ancla del fracaso futuro
Las empresas que llegaron hasta aquí haciendo las cosas de cierta forma tienen una razón legítima para desconfiar del cambio: les funcionó. Ese historial, que es un activo, opera como ancla cuando el contexto cambia.
Se manifiesta en la frase “asi lo hemos hecho siempre y nos ha ido bien”, que casi nunca es falsa. Es cierta y aun así no sirve para decidir hacia adelante.
4. Olvide los afectos y construya intereses
El cuarto error es apelar a la lealtad, la cultura o los valores compartidos como motor principal del cambio. El interés personal no es un obstáculo que haya que vencer: es la fuerza más potente disponible.
Jacinto Benavente lo dejó escrito en Los intereses creados. Críspin consigue que el posadero, el sastre y el banquero den crédito a su amo no por afecto, sino porque cada uno cree que va a beneficiarse. Cuando se descubre el engaño, todos terminan sosteniendo el desenlace que les conviene. La red de intereses hizo inevitable el resultado.
Llevado a un proyecto de ERP: la pregunta que cada persona se hace en silencio es qué gana ella con esto. Un plan que no la conteste, área por área y puesto por puesto, depende de la buena voluntad, y la buena voluntad se agota exactamente el día que el proyecto se pone difícil.
La respuesta no tiene que ser grandilocuente. “Vas a dejar de capturar lo mismo dos veces” es suficiente si es verdad.
5. Sus mayores críticos son consultores gratuitos
El error más caro es etiquetar a quien se resiste como enemigo del progreso. Esa postura defensiva impide ver que los críticos son la mejor fuente de información que hay en la empresa.
Quien se resiste rara vez lo hace por mala fe. Sus objeciones suelen señalar debilidades reales del plan: miedo a perder control, falta de confianza en el liderazgo, o un riesgo concreto que nadie más vio porque nadie más hace ese trabajo todos los días.
En vez de marginarlos, conviene formalizar su participación. Nombrar explícitamente a alguien como abogado del diablo, con el encargo de encontrar los puntos ciegos antes de que los encuentre la operación. Además de mejorar el plan, es la forma más eficaz de convertir a un detractor fuerte en alguien que defiende el proyecto.
Qué cambia en la práctica
Si estos cinco puntos son ciertos, el plan de adopción de un ERP no puede reducirse a un calendario de cursos. Tiene que incluir quién pierde control y cómo se compensa, qué gana cada área en concreto, y quién va a hacer el papel de crítico formal del proyecto.
Es también la razón por la que recorrer la operación departamento por departamento antes de configurar nada no es un trámite. Ahí es donde aparecen las fricciones que después explican por qué un módulo perfectamente configurado no se usa.
Preguntas frecuentes
¿Por qué la gente se resiste a un ERP nuevo?
Casi nunca por la herramienta. Se resiste a perder control sobre su propio trabajo y a que cambien las relaciones de dependencia e información dentro del equipo. Por eso la capacitación sola no resuelve la adopción.
¿Cómo se gestiona la resistencia al cambio en una implementación?
Contestando, puesto por puesto, qué gana cada persona, y dándole un papel formal a quienes más objetan en lugar de apartarlos. Sus objeciones suelen ser el mejor mapa de riesgos que tiene el proyecto.
¿Quién debe liderar la gestión del cambio?
Alguien de la empresa con autoridad para decidir, no el proveedor. El proveedor puede aportar el método, pero la legitimidad para pedirle a un área que cambie su forma de trabajar solo existe dentro de la organización.
Sobre cómo estructurar un proyecto para que la adopción no dependa de la buena voluntad, en la página de implementación de Odoo en México está el método que seguimos. Y si su proyecto ya se atascó, cómo recuperar una implementación fuera de control trata qué hacer primero.