El sistema cumple los requisitos, pasó las pruebas y la gente sigue usando la hoja de cálculo. El problema no es técnico.
La resistencia suele ser información, no obstrucción
Cuando un equipo rechaza un sistema nuevo, la lectura habitual desde la dirección es que la gente es reacia al cambio. Con frecuencia lo que ocurre es que el sistema no contempla un caso real que ese equipo maneja a diario y que nadie preguntó.
Escuchar esa objeción como información de diseño, y no como una actitud a vencer, suele revelar un requisito legítimo que faltaba.
Participación temprana de quien va a usarlo
Involucrar a los usuarios finales cuando el sistema ya está construido convierte cualquier observación suya en un cambio caro, lo que empuja a desestimarla. Involucrarlos en la definición hace que las mismas observaciones sean baratas.
No hace falta un comité: dos o tres personas que hacen el trabajo real, revisando prototipos cada dos semanas, cambian el resultado de forma sustancial.
Formación con los datos y casos propios
Una capacitación genérica sobre las funciones del sistema se olvida. Una sesión donde cada persona ejecuta sus propios casos con sus propios datos produce competencia real.
El momento también importa: formar tres semanas antes de la puesta en marcha garantiza que se olvide. La formación debe ser inmediatamente anterior al uso.
Retirar el proceso anterior en una fecha comprometida
Mientras la hoja de cálculo siga disponible, una parte del equipo la seguirá usando, y la información quedará repartida entre dos sitios, que es peor que cualquiera de los dos escenarios puros.
La retirada debe anunciarse con antelación, ocurrir en la fecha comprometida y contar con soporte reforzado esa semana. Postergarla repetidamente comunica que el cambio es opcional.