Adopción de un sistema nuevo: decide el jefe directo
Que tu equipo adopte un sistema nuevo lo decide el jefe directo de quienes operan, no el patrocinador del proyecto ni el área de innovación. Él define qué cuenta como trabajo terminado y qué se exige en la reunión del lunes. Si su informe todavía sale de la hoja de cálculo, el equipo sigue alimentando la hoja de cálculo.
¿Por qué pesa más el jefe directo que el patrocinador?
Porque está presente en el momento en que el operador elige entre el sistema nuevo y el camino antiguo. El patrocinador fija la prioridad una vez. El jefe directo la confirma o la deshace cada día, con lo que pregunta, el informe que pide y el atajo que tolera.
Eso no resta peso al patrocinio. En el estudio de Prosci, los proyectos con un patrocinador extremadamente eficaz cumplieron sus objetivos el 79% de las veces, frente al 27% con uno extremadamente ineficaz. Pero Prosci vende consultoría y formación en gestión del cambio, así que conviene leer sus cifras como investigación de una parte con interés en el tema. Lo que muestra es que el patrocinio abre la puerta. Lo que ocurre después lo decide quien convive con el equipo.
Para ti, como responsable de innovación, esto resulta incómodo. Normalmente no tienes autoridad jerárquica sobre quienes operan. Respondes por el resultado de una adopción que depende de personas que no te reportan.
¿Qué dicen los datos sobre el papel del jefe?
Dicen que el jefe directo concentra la influencia sobre el equipo, y que muchos no están preparados para ese papel cuando llega el cambio. Los datos tienen límites, y conviene decirlos primero.
Gallup afirma que los gerentes explican el 70% de la variación en el compromiso de los equipos. La cifra viene de investigación sobre compromiso, no sobre adopción de sistemas. Sirve como indicio de peso, no como pronóstico para tu proyecto.
El dato más cercano a nuestro tema es una encuesta de Gallup de mayo de 2025 a 19.043 adultos que trabajan en EE. UU. Entre los empleados de organizaciones que ya habían empezado a implantar IA, el 28% estuvo totalmente de acuerdo en que su jefe apoya activamente el uso de la tecnología por el equipo. Quienes estuvieron de acuerdo tenían 2,1 veces más probabilidad de usar IA varias veces por semana o más, y 6,5 veces más de considerar útiles las herramientas para su trabajo. Gallup no afirma causalidad, y el alcance es la IA en EE. UU., no un sistema interno de una empresa mediana. Aun así, el patrón es fácil de reconocer: el apoyo del jefe aparece junto con el uso.
Queda la preparación. Según Gallup, el 44% de los gerentes en el mundo ha recibido alguna vez formación en gestión. En la investigación de Prosci, el 43% de los participantes señala a los mandos intermedios como el grupo más resistente al cambio, y el 58% de los empleados prefiere oír el impacto personal de un cambio de su propio supervisor. Sin preparación y sin ser dueño del cambio, el jefe tiende a proteger la rutina del equipo, y desde su lugar eso es razonable. Es lectura nuestra, no un resultado de los estudios.
¿Dónde se rompe la adopción cuando el jefe no es el dueño?
Se rompe en tres puntos que los proyectos suelen dejar fuera del alcance: el informe que usa el jefe, la reunión que dirige y el camino antiguo que tolera.
El primero es el informe. Si el sistema se diseñó para quien carga el dato y no para quien exige el resultado, el jefe sigue pidiendo su hoja de cálculo. El operador carga en el sistema para cumplir con el proceso y en la hoja para cumplir con el jefe. La segunda tarea es la que hace con cuidado.
El segundo es la reunión. Mientras la agenda del lunes salga de otro archivo, el sistema nuevo es un registro paralelo, no el lugar donde se discute la operación.
El tercero es el camino antiguo. Si sigue funcionando, alguien lo usará bajo presión. Este patrón aparece en los casos donde el equipo vuelve a lo anterior después del lanzamiento, y medir el uso real permite ver qué equipos regresaron.
En los tres casos el defecto es de arquitectura. El sistema atiende el flujo del operador e ignora el flujo de control del jefe. En el caso de Reatop, por ejemplo, la app móvil nativa con uso sin conexión se pensó para quienes operan en campo y se conecta a un backoffice integrado. La adopción depende de que los dos lados se diseñen juntos.
Un ejemplo práctico: la hoja de las 8:30
El escenario siguiente es hipotético y las cifras son supuestos ilustrativos, no mediciones. Una distribuidora de 80 personas implanta un sistema de pedidos. El despacho tiene 12 operadores y un supervisor. Antes del sistema, el supervisor recibía a las 8:30 una hoja de cálculo con los envíos del día anterior y dirigía la reunión con la dirección a partir de ella.
El sistema entra en marzo. Los operadores reciben formación y cargan los pedidos en él. El supervisor, sin embargo, sigue pidiendo la hoja a las 8:30, porque la pantalla del sistema no muestra los pendientes por ruta, que es lo que la reunión necesita. En abril, 3 de los 12 operadores todavía mantienen la hoja, por si acaso. El proyecto declara la adopción al 100% porque los registros existen. El supervisor, que necesita la reunión de las 9:00 lista, sabe que la cifra real es otra.
Ahora el mismo escenario con el supervisor como dueño. Antes del lanzamiento, el equipo de implantación pregunta qué muestra el supervisor en la reunión y construye esa vista en el sistema, con pendientes por ruta. La reunión funciona sobre la pantalla. La hoja recibe una fecha de cierre, acordada con él y no impuesta. El operador ya no mantiene dos fuentes, porque quien pide el dato dejó de usar la antigua.
¿Cómo darle al jefe directo la propiedad del cambio?
En cuatro movimientos, todos antes del lanzamiento.
Primero, mapea la rutina de control del jefe: qué informe consulta, a qué hora, para qué reunión. Ese mapa define parte del alcance, y no es un añadido de formación.
Segundo, entrega su vista lista en el sistema. Si tiene que construir solo lo que la hoja le daba gratis, gana el camino antiguo.
Tercero, cambia de lugar la agenda de la reunión. La discusión semanal ocurre con el sistema abierto, y lo que no está en él no entra en la agenda. Eso cuesta una conversación con el jefe, no un proyecto.
Cuarto, fija con él la fecha de cierre del camino antiguo y sigue el uso por equipo, no solo el total. El uso total esconde al equipo que volvió a la hoja.
Preguntas frecuentes
Mi equipo no acepta cambios. ¿Cómo convenzo al jefe de que vale la pena?
Muéstrale lo que gana: la vista que hoy usa, lista, sin armar una hoja de cálculo cada lunes. La resistencia del jefe suele ser protección de la rutina del equipo, y se reduce cuando el cambio le entrega algo que ya usa. Convencer con discursos rinde menos que diseñar en torno al uso.
La implementación va a exigir demasiado tiempo del equipo. ¿Involucrar al jefe no la retrasa?
La retrasa poco al principio y ahorra tiempo después. La conversación para mapear la rutina de control lleva horas, mientras que operar dos caminos durante meses consume tiempo del operador y del jefe todos los días. El tiempo que gastas antes es menor que el costo de mantener viva la hoja de cálculo.
Temo que el sistema no elimine los cuellos de botella de verdad. ¿Qué cambia el jefe en eso?
Cambia lo que se ve. Si la reunión funciona sobre el sistema, los pendientes, los retrasos y las excepciones se vuelven visibles para quienes pueden actuar. Un cuello de botella que solo aparece en la hoja del supervisor no llega a la dirección ni al proceso, y el sistema pasa a ser un registro que nadie consulta.
El siguiente paso
Si quieres entender dónde la rutina de control de tus jefes directos todavía depende de un camino que el sistema nuevo no cubre, el Diagnóstico de Arquitectura Operacional, una conversación de 30 minutos, es una invitación para empezar: habla con Yowpi.
Cases relacionados
¿Reconociste tu operación en este artículo?
Agenda el Diagnóstico de Arquitectura Operacional: 30 minutos para mapear dónde está el cuello de botella de tu operación. Sin propuesta en la primera conversación.
Agendar diagnóstico