Gestión del cambio: por qué no se usa la automatización que se pidió
Una automatización que nadie usa entrega cero, aunque funcione. La causa rara vez es resistencia al cambio en abstracto: suele ser que la herramienta resuelve el problema del que la encargó y no el de quien tiene que usarla, o que resolverlo por el camino viejo sigue siendo más rápido.
A continuación: por qué falla la adopción, qué señales lo anticipan, cómo se diseña desde el inicio y qué medir después de entregar.
El proyecto terminó, la automatización pasó las pruebas y el informe dice que el proceso quedó resuelto. Tres meses después, la mitad del equipo sigue haciéndolo a mano.
Es un desenlace frecuente y casi siempre se diagnostica mal. Se atribuye a resistencia cuando la explicación suele ser más concreta y más fácil de corregir.
Las tres razones reales
El camino viejo sigue disponible y es más rápido. Si la persona puede resolver el caso como siempre en dos minutos, y la herramienta nueva exige abrir otra pantalla y esperar, elegirá lo primero. No es una preferencia: es aritmética.
La herramienta resuelve el problema equivocado. Quien la encargó quería reducir un costo; quien la usa quería dejar de perseguir información. Si el diseño optimizó lo primero e ignoró lo segundo, funciona y no sirve.
Nadie explicó qué pasa cuando falla. Una automatización que se detiene sin decir por qué genera desconfianza rápido, y la desconfianza es difícil de revertir: basta un caso perdido para que el equipo vuelva al método que entiende.
Las señales que lo anticipan
Se pueden ver antes de entregar. La primera es que nadie del equipo que usará la herramienta participó en definirla. La segunda es que el proyecto se justificó solo con ahorro de costo, sin un beneficio para quien hace el trabajo. La tercera es que no existe un plan para el caso que falla.
Cuando las tres están presentes, la adopción va a ser el problema, sin importar la calidad técnica del resultado.
Cómo se diseña la adopción desde el inicio
Involucrando a quien ejecuta el proceso en la definición, no en la validación final. La diferencia es sustancial: participar al principio produce una herramienta que encaja; revisar al final produce una lista de objeciones que llega tarde.
Y dando un beneficio directo a quien la usa. Menos búsqueda de información, menos preguntas que responder, menos trabajo repetido. El ahorro de costo es el argumento para quien aprueba; no es el argumento para quien adopta.
Cuando el proceso se rediseña además de automatizarse, conviene que ese rediseño se haga con los usuarios y no sobre ellos. Es la misma lógica que sostiene un enfoque de Design Thinking: entender el problema real antes de construir la solución.
Esa conversación tiene que ocurrir en el idioma y el horario de quien hace el trabajo. Acompañamos la adopción desde Bogotá y Ciudad de México, dentro de la jornada del equipo que va a usar la herramienta: una sesión de dudas a las tres de la tarde resuelve lo que un material de capacitación enviado de madrugada no resuelve nunca.
Quién debe contar la historia
El anuncio importa más de lo que suele reconocerse, y casi siempre lo hace la persona equivocada. Cuando el mensaje llega de TI, la automatización se percibe como algo que le ocurre al equipo; cuando lo da el responsable del proceso, se percibe como algo que el equipo consiguió.
También cambia el contenido. Un anuncio técnico explica qué hace la herramienta; el que funciona explica qué deja de hacer la persona y a quién preguntar cuando algo no salga como se espera. Esa segunda parte es la que evita que el primer tropiezo se convierta en abandono.
Retirar el camino viejo, y cuándo
Mientras existan dos formas de hacer lo mismo, una ganará. Cerrar el camino anterior es lo que consolida la adopción, y es también la decisión que más se posterga por miedo a romper algo.
La secuencia que funciona es medir primero: cuando la herramienta nueva resuelve la mayoría de los casos y el equipo confía en ella, retirar la alternativa es un trámite. Hacerlo antes de esa confianza produce exactamente el incidente que se temía.
Qué medir después de entregar
Tres cifras, revisadas durante los primeros meses. Qué porcentaje de los casos pasa por la automatización —no cuántos podría, cuántos lo hacen—. Cuántas excepciones genera y por qué. Y cuánto tarda alguien en resolver una.
La primera es la que dice si el proyecto entregó. Si el ochenta por ciento del volumen sigue yendo por fuera, la automatización existe y el proceso no cambió. Esa medición forma parte de operar la capacidad de automatización, no de cerrarla.
Preguntas frecuentes
¿Por qué la gente no usa una automatización que funciona?
Casi siempre porque el camino anterior sigue disponible y es más rápido para el caso concreto, porque la herramienta resolvió el problema de quien la encargó y no el de quien la usa, o porque nadie explicó qué hacer cuando falla.
¿Cómo se anticipa un problema de adopción?
Tres señales antes de entregar: nadie del equipo usuario participó en la definición, el proyecto se justificó solo con ahorro de costo, y no hay plan para el caso que falla.
¿Conviene retirar el proceso manual anterior?
Sí, pero después de que la herramienta resuelva la mayoría de los casos y el equipo confíe en ella. Mientras existan dos formas de hacer lo mismo, una gana; retirarla antes de esa confianza provoca el incidente que se temía.
¿Qué se mide para saber si la adopción funcionó?
El porcentaje de casos que realmente pasa por la automatización, cuántas excepciones genera y por qué, y cuánto se tarda en resolver una. La primera es la que dice si el proyecto entregó.
