«Eso no va a funcionar aquí»: cómo gestionar la resistencia al cambio cuando se implementa un software

«Eso no va a funcionar aquí»: cómo gestionar la resistencia al cambio cuando se implementa un software

En Wide Solutions llevamos 17 años implementando sistemas en empresas ecuatorianas, y hay un momento que se repite en casi todos los proyectos: alguien del equipo —a veces el que más sabe del negocio— dice que el software nuevo no va a funcionar. No lo dice por capricho. Lo dice porque ha visto implementaciones anteriores que se anunciaron con bombos y platillos y terminaron en abandono, con la operación volviendo al Excel y al cuaderno.

Esa resistencia no es un obstáculo menor ni un problema de actitud. Es una señal que conviene leer con atención, porque suele contener la información más valiosa del proyecto: los procesos reales que ningún manual recoge. Este artículo trata de cómo trabajarla, no de cómo silenciarla.

Por qué el equipo se resiste (y por qué tiene razones)

Antes de calificar a alguien de «resistente», ayuda entender qué está defendiendo. En la mayoría de los casos es una de estas cuatro cosas:

• Miedo a quedar expuesto. Si el sistema muestra lo que cada persona hace y cuánto tarda, quien nunca tuvo sus números a la vista teme que el cambio lo deje en evidencia. Es un temor legítimo y se responde con transparencia, no con discursos motivacionales.
• Experiencias previas que salieron mal. Un sistema que prometía mucho y no se adaptó, una migración que perdió datos, un proveedor que desapareció después de cobrar. La desconfianza tiene memoria.
• Percepción de pérdida de control. Quien domina un proceso con su propio método —su cuaderno, su archivo, su rutina— siente que el sistema le quita ese dominio. Si nadie le explica qué gana a cambio, solo ve lo que pierde.
• El trabajo real que el sistema no contempla. A veces la objeción es técnica y precisa: «esto no funciona así en nuestra bodega». Esa observación puede evitar meses de retrabajo si se escucha a tiempo.

Vale la pena notar que los cuatro motivos apuntan a lo mismo: la gente no se resiste al software, se resiste a la incertidumbre. Un cambio anunciado sin explicación, sin fechas claras y sin acompañamiento es incertidumbre pura.

Lo que no funciona: imponer y esperar obediencia

Las estrategias más comunes para «resolver» la resistencia son también las que más daño hacen:

• Decidir arriba y comunicar abajo el mismo día. El equipo se entera de que cambia su forma de trabajar cuando ya está en marcha. La reacción natural es defenderse.
• Capacitar como si todos fueran iguales. Una sesión de dos horas para todos, sin distinguir quién usa el sistema todo el día de quien lo toca una vez por semana.
• Castigar el uso incorrecto antes de asegurar el uso correcto. Se miden errores de digitación cuando todavía nadie sabe dónde está cada botón.
• Ignorar la objeción técnica. Se responde «el sistema ya está definido» a alguien que conoce el proceso mejor que el implementador. Esa persona deja de colaborar y el conocimiento se pierde.

Ninguna de estas prácticas elimina la resistencia; la hace invisible y la traslada al uso diario: se opera el sistema nuevo «por cumplir» y se sigue trabajando por fuera.

Lo que sí funciona: seis movimientos concretos

1. Involucrar a quien hace el trabajo antes de configurar

Antes de definir pantallas y permisos, conviene sentarse con quienes ejecutan el proceso. No para consultarles cada decisión, sino para entender cómo trabaja realmente la operación, qué excepciones existen y dónde el procedimiento escrito no coincide con la práctica. Ese diagnóstico no solo mejora la implementación: convierte a los usuarios en parte del proyecto en lugar de víctimas de él.

2. Explicar el «para qué», no solo el «cómo»

La capacitación técnica enseña a usar el sistema. No explica por qué se cambia. Cuando alguien entiende que el inventario al día evita que la bodega prometa lo que no tiene, o que la información en tiempo real elimina el cierre de mes de tres días, la tarea tiene sentido y el esfuerzo se justifica. Sin ese «para qué», el sistema es solo una tarea más.

3. Nombrar aliados internos, no solo supervisores

En cada área hay personas con credibilidad ante sus compañeros. Son las que resuelven dudas, las que dicen «esto sí sirve» y las que el resto escucha. Sumarlas temprano —como usuarios de referencia, no como policías— multiplica la adopción mucho más que cualquier instrucción de la gerencia.

4. Cambiar por etapas, con victorias visibles

Reemplazar todo a la vez concentra el riesgo y la ansiedad. Un avance por etapas —un módulo, un área, una sucursal— permite ajustar sobre la marcha y genera resultados tempranos que el equipo puede ver. La primera victoria concreta, sea un cierre más rápido o un reporte que antes no existía, vale más que diez presentaciones.

5. Medir la adopción, no solo la asistencia

Saber cuántas personas asistieron a la capacitación dice poco. Lo que importa es cuántos usan el sistema para lo que debe usarlo, cuántas transacciones se registran en él y cuántas siguen ocurriendo por fuera. Medir eso a las pocas semanas permite corregir a tiempo, antes de que la costumbre se consolide.

6. Acompañar después del go-live

El día en que el sistema entra en producción es el día en que empiezan las dudas reales. Un soporte accesible durante esas primeras semanas —para resolver el error de la factura, la duda del stock, el reporte que no sale— evita que la frustración se convierta en abandono. La implementación no termina cuando el sistema arranca; empieza ahí.

El caso de la objeción técnica: escucharla es ahorrar

Hay un tipo de resistencia que merece un trato aparte: la que viene con un argumento concreto y verificable. «Este producto se mide en dos unidades distintas», «este cliente paga en tres partes», «la bodega despacha por lotes, no por unidades». Cuando alguien plantea esto, no está bloqueando el proyecto; está aportando información que, si se ignora, aparecerá después como un problema del sistema.

Escuchar y validar esas observaciones tiene un costo pequeño —una conversación, un ajuste de configuración, a veces un desarrollo puntual— frente al costo de descubrirlas tres meses después, cuando el equipo ya perdió la confianza en la herramienta. La regla práctica es simple: si la objeción describe un hecho de la operación, se investiga; si describe una preferencia, se conversa. Confundir las dos cosas en cualquiera de las dos direcciones cuesta caro.

Cómo lo abordamos en Wide Solutions

En Wide Solutions no tratamos la implementación como la entrega de un producto terminado. Trabajamos con cada empresa en el análisis de su operación, la configuración de la plataforma SIVO, la capacitación de su equipo y el soporte posterior. Ese acompañamiento local —con personas que conocen el contexto tributario y operativo del país— es parte de por qué nuestros proyectos se sostienen en el tiempo.

Con 17 años de experiencia en distintos sectores, hemos aprendido que el factor que más define el éxito de un sistema no es la cantidad de funcionalidades, sino cuánto lo usa el equipo y qué tan bien se adaptó a cómo trabaja la empresa. También ofrecemos integración con los sistemas existentes y desarrollo a la medida cuando el proceso lo requiere.

Si estás por implementar un sistema —o ya lo intentaste y no prendió— podemos revisar juntos dónde está el freno real y qué hace falta para que el equipo lo adopte. Conversemos.