Plan de gestión del cambio: resuelva la resistencia antes de que empiece

Un plan de gestión del cambio para un programa ERP establece cómo pasarán las personas de la forma en que trabajan hoy a la forma en que el nuevo sistema necesita que trabajen, y quién es responsable de llevarlas hasta allí. Empieza en la movilización, no en la formación. Tiene siete partes, cada una con un responsable con nombre, y se integra en el acta de constitución del proyecto, en los talleres de diseño y en los quality gates en lugar de gestionarse como un frente paralelo.

La mayor parte de la resistencia no surge de la nada. Se gesta lentamente, mucho antes del arranque. Se oye en comentarios de pasada en las primeras reuniones. Se nota cuando los responsables clave del negocio se quedan callados. Cuando se redacta un plan formal de cambio, buena parte del daño ya está hecho.

Suele empezar en unos pocos lugares predecibles:

1. Usuarios clave excluidos del diseño temprano.
2. Jefes de departamento sorprendidos por impactos que nadie habló con ellos.
3. Comunicación vaga que invita a cuestionarlo todo.
4. Proyectos fallidos del pasado que dejaron una desconfianza silenciosa.

Son problemas estructurales, no solo de comunicación. Si el comité directivo es pasivo, espere fricción. Si el acta de constitución del proyecto no dice nada sobre la adopción, ya ha perdido una palanca.

1. 01MovilizaciónMapee la influencia y recoja la historia informal
2. 02DiseñoAcuerde los KPI de adopción, los power users son coautores
3. 03PruebasLos usuarios de negocio prueban sus propios procesos
4. 04FormaciónPor roles, con datos reales, en horarios a los que la gente pueda asistir
5. 05Punto de control de go-liveUmbrales de adopción, no solo aprobación funcional
6. 06Primeros 90 díasSiga los inicios de sesión, errores, tickets y soluciones alternativas

Soluciones alternativas detectadas antes de que se conviertan en hábito

Un plan de cambio no es un calendario de comunicaciones. Estos son los siete componentes y quién debería ser responsable de cada uno.

Componente	Propósito	Responsable
Mapa de roles e influencia	Todas las personas afectadas, con su influencia, no solo su cargo	Líder de cambio
Evaluación del impacto del cambio	Cómo cambian los roles, procesos y herramientas de cada grupo	Propietarios de procesos con el equipo de cambio
Plan de comunicación	Audiencias, mensajes, canales y momentos, con ciclos de retroalimentación	Responsable de comunicación
Formación y capacitación	Currículo por roles, práctica, comprobaciones de preparación	Responsable de formación
Implicación del liderazgo	Líderes alineados, informados y que respaldan el cambio de forma visible	Patrocinador ejecutivo con el líder de cambio
KPI de adopción	Medidas de comportamiento acordadas en el diseño y seguidas después del go-live	Líder de cambio
Seguimiento de la resistencia	Señales tempranas de alerta asignadas a equipos	Todos los líderes de frentes de trabajo

La comunicación en la mayoría de los planes de cambio significa boletines, correos y reuniones generales. No es eso lo que mueve a las personas.

Recuerdo un despliegue en el que lo comunicamos todo a tiempo, pero nadie sabía explicar por qué cambiaba el proceso. Teníamos volumen, pero no claridad.

Adapte el mensaje a cada audiencia. Los altos directivos quieren ver primero el impacto en el negocio. Los usuarios finales necesitan oírlo de su propio jefe, no de un líder de programa al que nunca han visto. Los responsables funcionales responden mejor cuando son dueños de una parte del mensaje.

Integre la retroalimentación. La comunicación que solo sale hacia fuera es medio plan. Trabajé con un equipo en el que las llamadas semanales de preguntas y respuestas lograron más que cualquier correo. Vincule lo que oiga con el registro de riesgos, para que los puntos débiles se vean antes de que salgan a la luz en público.

Acierte con el momento. Demasiado pronto genera confusión. Demasiado tarde parece forzado. En un despliegue, los usuarios pensaron que sus puestos iban a ser reemplazados. Nadie dijo eso. Pero el silencio llenó los huecos. Aborde el miedo de frente y pronto, antes de que otro lo haga por usted.

No reutilice el mapa de personas del último proyecto. La influencia cambia de un programa a otro. Construya el mapa desde cero y actualícelo cada mes.

Para cada persona, registre tres cosas: cuánto la afecta el cambio, dónde se sitúa hoy (a favor, neutral o resistente) y cuánta influencia tiene sobre los demás. Un mando intermedio resistente cuyo equipo lo sigue importa más que un usuario individual resistente.

Recoja también la historia informal. Los proyectos fallidos del pasado moldean el comportamiento de maneras que los documentos de lecciones aprendidas nunca registran. Unas horas escuchando lo que la gente recuerda le dicen con qué se está enfrentando realmente. Mi guía de gestión de partes interesadas explica el mapeo con más detalle.

La formación es una parte de la gestión del cambio, no su totalidad. El fallo habitual es una formación que llega demasiado tarde, en el formato equivocado, y que se detiene antes de que la gente se sienta segura. Un curso de un día dos semanas antes del go-live no es preparación.

Lo que funciona:

1. Contenido por roles. Enseñe a cada grupo lo que necesita para su propio trabajo, no un recorrido por el sistema.
2. Práctica con datos reales. Use los datos y las transacciones del propio negocio, no escenarios de demostración.
3. Power users como formadores. Las personas aprenden mejor de colegas en quienes confían. Trate a los power users como coautores del diseño, no solo como probadores.
4. Formación en el momento adecuado. Un equipo de finanzas con el que trabajé se saltaba las sesiones porque estaban programadas a una mala hora. Cambiarlas lo resolvió.
5. Soporte después del go-live. La confianza cae después del go-live, no antes. Dote el hypercare de personas que sepan responder rápido a preguntas reales.

Las pruebas de aceptación de usuario (UAT) también forman parte de la adopción. Recuerdo una sesión de UAT en la que un pequeño error en la lógica de precios habría provocado facturas incorrectas. Un jefe de equipo lo detectó. Nadie más lo había visto. Esa única detección ahorró semanas de limpieza, y ocurrió porque un usuario de negocio sentía que el sistema era en parte suyo.

Incluya umbrales de adopción en sus quality gates. «El sistema funciona» es una aprobación funcional. «Los usuarios están listos para trabajar en él» es otra distinta, y la mayoría de los programas solo piden la primera. Mi guía sobre estrategias de formación en SAP profundiza en el plan de formación.

KPI de adopción que conviene acordar antes del go-live

Defínalos durante el diseño, para tener una línea base con la que medir:

1. Tasas de inicio de sesión por grupo de usuarios en los primeros 90 días.
2. Tasas de error en transacciones clave frente a la línea base del sistema heredado.
3. Tickets de soporte por volumen y categoría.
4. Frecuencia de soluciones alternativas: exportaciones a hojas de cálculo, registros paralelos, aprobaciones manuales fuera del sistema.
5. Confianza declarada por los responsables, medida con encuestas de pulso breves.

La ventana es estrecha. He visto usuarios volver discretamente a las hojas de cálculo en cuestión de semanas, no porque el sistema estuviera roto sino porque nadie los ayudó a atravesar el cambio. Pocos meses después del go-live, las soluciones alternativas se convierten en hábitos.

Herramientas de adopción digital

SAP completó la adquisición de WalkMe en septiembre de 2024, por un valor patrimonial de unos 1,5 mil millones de dólares. SAP dijo entonces que las capacidades de IA de WalkMe añadirían ayuda contextual a Joule en todos los flujos de trabajo. Eso significa que SAP es hoy propietaria de dos herramientas de adopción con fortalezas distintas:

• SAP Enable Now es adecuada para el contenido de formación estructurado: se graba un proceso una vez y se generan a partir de él documentación, simulaciones y scripts de prueba.
• WalkMe es adecuada para la guía dentro de la aplicación en el momento de uso, y puede abarcar aplicaciones SAP y no SAP.

Evalúelas juntas. Whatfix es la principal alternativa independiente si quiere herramientas de adopción que no estén atadas a SAP. Ninguna de estas herramientas sustituye a un jefe que explique por qué importa el cambio.

Incluso con buena preparación, aparece fricción nueva. Controlarla en exceso suele ser contraproducente. El objetivo es verla pronto.

Las señales de alarma son talleres a los que no se asiste, silencios en las reuniones, comentarios vagos en las pruebas y usuarios clave que construyen soluciones alternativas no oficiales. Asigne cada señal al equipo del que procede, para poder actuar antes de que llegue al comité directivo.

Una práctica que funciona: rotar a los líderes de cambio por fase. Una sola persona al frente del cambio durante un programa de dos años suele quemarse y perder perspectiva. A medida que cambia la naturaleza de la resistencia, deberían cambiar también las personas que la gestionan.

Sobre todo, mantenga la gestión del cambio dentro de la estructura del programa. Los resultados de comportamiento pertenecen al acta de constitución del proyecto. Los riesgos de personas, como la sobrecarga de los equipos y la desconfianza heredada, pertenecen al registro de riesgos junto a los técnicos. Cuando la gestión del cambio informa dentro de un informe genérico de la PMO, se reduce a marcar casillas.

Esta guía forma parte de mi guía central de implantación de SAP, que enlaza todos los temas, desde el caso de negocio hasta la puesta en marcha.

¿Qué debe incluir un plan de gestión del cambio?

Siete partes: mapa de influencia, evaluación del impacto del cambio, plan de comunicación con ciclos de retroalimentación, formación por roles, implicación del liderazgo, KPI de adopción y seguimiento de la resistencia. Cada una necesita un responsable con nombre, y el plan debe vincularse al acta de constitución, a los talleres de diseño y a los quality gates.

¿Cuáles son las 5 C de la gestión del cambio?

Hay varias versiones. La que yo uso es claridad (la gente sabe qué cambia para ella), coherencia (los líderes dicen lo mismo), compromiso (el patrocinador se mantiene visible), comunicación (relevante, oportuna y bidireccional) y capacidad (formación, soporte y tiempo para adaptarse). Si falta cualquiera de ellas, la gente vuelve a los viejos hábitos.

¿Cuáles son las 7 R de la gestión del cambio?

Proceden de la gestión de servicios de TI y se usan para evaluar una solicitud de cambio antes de actuar. Quién la planteó, el motivo, el retorno esperado, los riesgos, los recursos necesarios, quién es responsable y la relación con otros cambios. Se aplican al control técnico de cambios más que al lado humano de un programa.

¿Cuál es la diferencia entre la gestión del cambio organizativo y la técnica?

La gestión del cambio organizativo prepara a las personas: comunicación, formación y soporte durante un cambio en su forma de trabajar. La gestión técnica del cambio controla qué cambios entran en el sistema SAP, mediante transportes, aprobaciones, pruebas y marcha atrás. Los programas ERP suelen gestionar bien el lado técnico; los fracasos de adopción vienen del lado organizativo. Mi guía sobre herramientas de gestión técnica del cambio en SAP cubre el lado técnico.

¿Debo usar WalkMe o SAP Enable Now?

A menudo, ambas. SAP Enable Now es más sólida para crear contenido de formación estructurado antes del go-live. WalkMe es más sólida para la guía dentro de la aplicación después del go-live, sobre todo cuando los usuarios se mueven entre SAP y otras aplicaciones. Como SAP es propietaria de ambas, evalúelas juntas. Whatfix es la principal alternativa independiente.

¿Cuándo debe empezar la gestión del cambio en un proyecto ERP?

En la movilización, antes del primer taller de diseño. Las primeras acciones que más importan son mapear la influencia, recoger la historia informal de proyectos pasados, incluir los resultados de comportamiento en el acta de constitución y fijar el ritmo de comunicación del patrocinador.