Imaginemos una empresa de servicios que implanta una nueva plataforma de inteligencia artificial para atender a sus clientes. La dirección anuncia una mejora radical de la productividad. Se rediseñan algunos procedimientos, se forma a toda la plantilla y, seis meses después, el cuadro de mando parece impecable: todos los empleados utilizan la aplicación, casi todas las gestiones pasan por el nuevo sistema y las encuestas internas dicen que la herramienta resulta cómoda. Si el éxito se midiera por la adopción, el proyecto sería un caso de manual.
Sin embargo, el negocio no mejora como se esperaba. Los casos sencillos se resuelven más deprisa, pero los complejos se enquistan. Han desaparecido algunas comprobaciones informales que evitaban errores y que nadie había documentado, de modo que aumenta el trabajo de corrección. Los empleados más expertos intervienen cada vez menos en la resolución cotidiana y, cuando surge una excepción, nadie sabe con certeza quién debe decidir. La dirección ha conseguido que todos utilicen un sistema que ha hecho a la organización más rápida en unas tareas, pero menos competente en su conjunto.
El ejemplo es ficticio, pero cualquiera que haya dirigido o sufrido una transformación reconocerá cada uno de sus síntomas. Y todos ilustran una misma distinción, que es la idea sobre la que se construye este artículo: conseguir que una organización adopte un cambio no equivale a demostrar que ese cambio era el correcto. Un proyecto puede entregarse en plazo, una herramienta puede funcionar sin errores y la plantilla puede utilizarla con soltura sin que la empresa obtenga ningún valor. Incluso puede ocurrir algo peor, que es lo que le ha pasado a la empresa del ejemplo: que el cambio destruya capacidades que la organización tenía antes y que nadie había identificado como valiosas porque nunca habían aparecido en un procedimiento.
Buena parte de la crítica reciente a los modelos clásicos de gestión del cambio, y en particular a ADKAR, apunta a esa herida: adoptar no es transformar. La advertencia es acertada, pero de ella no se desprende que ADKAR sea inútil, ni que lo sean Kotter, Lewin o el resto de los modelos clásicos. Lo que se desprende es que la adopción individual es una parte de un problema más amplio, y que tratarla como si fuera el problema entero es una forma muy eficaz de implantar con éxito un cambio equivocado.
Ese problema más amplio puede formularse con cinco preguntas. Una transformación bien dirigida tiene que responderlas al principio y, lo que es más importante y más raro, volver a responderlas a medida que aprende, porque los datos que aparecen durante el camino pueden invalidar las respuestas iniciales:
- ¿Por qué necesitamos cambiar? Qué problema, amenaza u oportunidad justifica el esfuerzo, y cuánto cuesta no hacer nada.
- ¿Qué deberíamos cambiar? Qué parte del modelo de negocio, de las capacidades, de los procesos, de las responsabilidades o de las decisiones tiene que evolucionar.
- ¿Cómo construiremos la solución? Con qué tecnología, datos, organización, recursos, controles y método de ejecución.
- ¿Cómo conseguiremos que funcione en la práctica? Cómo cambiarán los comportamientos, las competencias, los incentivos y las rutinas de quienes van a trabajar con ella.
- ¿Cómo sabremos que fue una buena decisión? Qué resultados verificaremos, qué efectos inesperados buscaremos y en qué condiciones corregiremos o detendremos la iniciativa.
Los modelos clásicos de gestión del cambio responden muy bien a la cuarta pregunta y, en parte, a la primera. Son mucho menos útiles para la segunda, la tercera y la quinta, que es donde se decide si la transformación crea valor. Por eso este artículo no presenta un modelo más, sino una metodología para dirigir una transformación de principio a fin: cómo se integran las disciplinas, quién toma cada decisión y cómo se comprueba que el cambio funciona. Integra Kotter, ADKAR, Lewin y McKinsey 7S con el diagnóstico de procesos, el diseño organizativo de Nadler-Tushman y Galbraith, los sistemas sociotécnicos, la gestión de proyectos, el gobierno de la inteligencia artificial, la medición del valor y el aprendizaje de doble bucle de Chris Argyris, y sitúa cada uno en la pregunta para la que fue diseñado.
La metodología sirve para implantar un ERP o un CRM, para transformar la atención al cliente, para integrar operaciones después de una adquisición, para automatizar procesos o para rediseñar el trabajo con inteligencia artificial. La dimensión tecnológica cambia de un caso a otro, pero las preguntas de dirección son siempre las mismas. Para que no se quede en un marco abstracto, la empresa de servicios del ejemplo inicial reaparecerá a lo largo del texto, y cada etapa terminará con las herramientas concretas que hacen falta para recorrerla: plantillas, matrices, criterios de decisión y preguntas que un comité de dirección puede llevar a su próxima reunión. El objetivo es que quien termine de leer sepa qué hacer el lunes, no solo qué pensar.
Transformación empresarial, digitalización, automatización y gestión del cambio: qué diferencia cada concepto
Muchas iniciativas fracasan antes de empezar por una confusión de conceptos que después contamina sus objetivos y sus indicadores. Si un proyecto se llama transformación pero en realidad es una digitalización, se le exigirán resultados que no puede dar. Y si es una transformación que se gestiona como una digitalización, se medirá con indicadores que no detectan lo que importa. Antes de definir cualquier objetivo conviene saber qué tipo de cambio se está acometiendo, porque cada uno tiene una ambición, un riesgo y una forma de medirse distintos.
Digitalizar significa convertir actividades, documentos o información en flujos digitales, como cuando un formulario en papel se sustituye por una aplicación. Automatizar supone reducir o eliminar intervenciones manuales, de modo que un paso que antes hacía una persona lo haga ahora un sistema. Optimizar consiste en mejorar un proceso, manteniendo o no su lógica fundamental: eliminar dos aprobaciones redundantes o reordenar las tareas para reducir esperas. Transformar, en cambio, implica modificar de manera significativa cómo la organización crea y entrega valor, qué capacidades necesita y cómo articula el trabajo, la tecnología y las decisiones.
De estas definiciones se siguen dos consecuencias que conviene tener presentes. La primera es que no toda instalación de software es una transformación: implantar un nuevo sistema de nóminas puede ser una mejora excelente sin cambiar nada de cómo compite la empresa. La segunda, menos evidente, es que no toda transformación necesita tecnología nueva. Un rediseño de responsabilidades comerciales, de incentivos o de la relación entre departamentos puede alterar una empresa mucho más profundamente que una gran migración informática. Cuando Alan Mulally reorganizó Ford alrededor de una única reunión semanal de revisión del negocio, el cambio que salvó a la compañía no fue tecnológico, sino de cómo se compartía la información y se tomaban las decisiones. Y a la inversa, una tecnología nueva puede rendir muy poco si el modelo de trabajo queda intacto: es lo que ocurrió con las fábricas que sustituyeron la máquina de vapor por motores eléctricos sin reorganizar la planta, una historia que se cuenta en el análisis de la IA frente a las grandes revoluciones de la historia.
Dirección de la transformación, gestión de proyectos y gestión del cambio: tres disciplinas distintas
La segunda confusión, y probablemente la más dañina, es la que mezcla tres disciplinas que deben colaborar pero no confundirse. Muchas consultoras las venden como un solo servicio y muchas empresas las asignan a una sola persona, con el resultado de que una de ellas, casi siempre la primera, desaparece sin que nadie lo note. Cada disciplina responde a una pregunta distinta, tiene una responsabilidad distinta y se mide de una manera distinta.
| Disciplina | Pregunta principal | Responsabilidad característica | Cómo se reconoce el éxito |
| Dirección de la transformación | ¿Estamos construyendo una organización mejor? | Estrategia, modelo futuro, decisiones de inversión y captura de beneficios | Menores costes estructurales, más ingresos o mejor servicio sin deteriorar calidad, resiliencia ni cliente |
| Gestión de proyectos y productos | ¿Estamos entregando la solución adecuada con calidad y control? | Diseño, desarrollo, integración, pruebas, implantación y evolución | Una solución fiable, disponible y compatible con los procesos que la necesitan |
| Gestión del cambio organizativo | ¿Pueden y quieren las personas trabajar eficazmente de otra manera? | Patrocinio, participación, comunicación, formación, acompañamiento y hábitos | Un uso competente y sostenido del nuevo modelo de trabajo |
La tabla deja ver por qué la adopción es tan importante y, a la vez, tan engañosa. Es el eslabón que conecta la solución con los beneficios esperados: sin adopción no hay beneficio posible. Pero no sustituye ni a la calidad del diseño ni a la validez de la estrategia. A la inversa, un modelo operativo magnífico sobre el papel no crea valor si nadie consigue hacerlo funcionar. Las tres disciplinas son necesarias, y el fracaso de cualquiera de ellas arrastra a las otras dos.
De ahí se deriva la primera regla práctica de toda la metodología: el éxito se define en resultados de negocio y en capacidades organizativas, nunca en hitos de implantación. «Hemos lanzado el ERP», «hemos formado a doscientas personas» o «el 95 % de la plantilla usa Copilot» describen actividad o adopción. Son datos útiles para gestionar el proyecto, pero no prueban ninguna mejora empresarial. Un buen test consiste en tomar el objetivo oficial del programa y preguntarse si podría cumplirse al cien por cien mientras el negocio empeora. Si la respuesta es sí, como le ocurría a la empresa del ejemplo, el objetivo está mal formulado y hay que reescribirlo antes de seguir.
Por qué fracasan las transformaciones empresariales: cinco puntos de ruptura, uno por cada pregunta sin responder
Casi todos los artículos sobre este tema empiezan con la misma cifra: el 70 % de las transformaciones fracasa. Conviene detenerse un momento en ella, porque lo que revela es más útil que lo que afirma. En 2011, Mark Hughes revisó en el Journal of Change Management las cinco fuentes que se citaban habitualmente para sostenerla y concluyó que ninguna aportaba evidencia empírica válida. Las mediciones posteriores tampoco coinciden entre sí: el estudio de BCG que más se cita reparte los programas en un 30 % que alcanza sus objetivos, un 44 % que los alcanza solo en parte y un 26 % que no los alcanza, mientras que los directores de proyecto encuestados por el PMI declaran tasas de fracaso de entre el 8 % y el 11 %. No existe ninguna medición externa y auditada de cuántas transformaciones fracasan, y eso, en sí mismo, es el dato importante.
Que no exista esa medición no se debe a falta de interés, sino a que casi ninguna empresa define al principio qué significaría fracasar. Si el objetivo de un programa es «implantar la nueva plataforma», el programa tendrá éxito el día que la plataforma esté implantada, aunque el negocio no haya mejorado. Por eso las encuestas a quienes dirigen los proyectos dan cifras de fracaso bajas, y las que preguntan por los beneficios capturados dan cifras altas. Lo que sí repiten muchos de esos estudios es que las empresas capturan menos valor del que prometían al aprobar la inversión. La pregunta útil no es cuántas transformaciones fracasan, sino en qué momento se rompen, porque eso es lo que se puede prevenir.
Hay una idea muy extendida, y en buena parte cierta: implantar un ERP, un CRM o una capa de automatización rara vez fracasa por la tecnología en sí. Pero esa idea, llevada al extremo, conduce a otro error, que es atribuir todos los fracasos a la resistencia de las personas. Cuando se reconstruye cómo se tuerce una transformación concreta, la ruptura casi nunca está en un único sitio, y casi siempre coincide con una de las cinco preguntas de la introducción que alguien dio por respondida demasiado pronto.
El primer punto de ruptura es un problema mal definido. La empresa elige la solución antes de entender qué está fallando, y lo hace con frases como «necesitamos un CRM» o «hay que implantar IA», que no describen ningún problema de negocio. El proyecto se ejecuta bien, pero ataca un síntoma, y el problema de fondo sigue ahí cuando termina. El segundo es un diseño incompleto: se cambia la herramienta, pero no el trabajo, las decisiones, los incentivos ni las responsabilidades que la rodean, de modo que la nueva tecnología queda atrapada en el modelo organizativo antiguo.
El tercer punto de ruptura es una ejecución sin autoridad. El programa tiene un comité, un calendario y un presupuesto, pero nadie con poder suficiente para resolver los conflictos entre áreas, que son inevitables porque toda transformación redistribuye trabajo, información y poder. El cuarto es una adopción superficial: el sistema se usa, pero las personas siguen trabajando como antes, mantienen la hoja de cálculo paralela y recurren a la consulta informal cuando la herramienta no responde. Y el quinto es un valor que nadie verifica, porque el proyecto se cierra con la puesta en marcha, el equipo se disuelve y nadie tiene la responsabilidad de comprobar si aparecen los beneficios que justificaron la inversión.
La tabla siguiente resume cada punto de ruptura con el síntoma que lo delata y la disciplina que lo previene. Su utilidad práctica es que permite leer el estado de un programa en curso: si el síntoma de una fila aparece, la solución no está en esa fila de síntomas sino en la disciplina de la última columna, que probablemente nadie está ejerciendo.
| Punto de ruptura | Síntoma visible | Pregunta que quedó sin responder | Disciplina que lo previene |
| Problema mal definido | El objetivo del programa es implantar algo, no conseguir algo | ¿Por qué necesitamos cambiar? | Diagnóstico causal y caso de transformación |
| Diseño incompleto | La herramienta funciona y el proceso sigue igual de lento | ¿Qué deberíamos cambiar? | Diseño organizativo y sociotécnico |
| Ejecución sin autoridad | Los conflictos entre áreas se resuelven con excepciones o con retrasos | ¿Cómo construiremos la solución? | Gobierno del programa y gestión de proyectos |
| Adopción superficial | Sistemas paralelos, consultas informales y vuelta a los hábitos anteriores | ¿Cómo conseguiremos que funcione? | Gestión del cambio y liderazgo |
| Valor no verificado | El programa se celebra al arrancar y nadie mide el resultado | ¿Cómo sabremos que fue una buena decisión? | Medición del valor y aprendizaje de doble bucle |
Lo más revelador de la tabla es su penúltima fila. Los modelos de gestión del cambio, que son lo que la mayoría de las empresas entiende por «metodología de transformación», actúan casi exclusivamente sobre el cuarto punto de ruptura. Son imprescindibles para él y apenas dicen nada de los otros cuatro. Una organización que solo dispone de esos modelos puede hacer muy bien la parte que conoce y fracasar igualmente por las otras cuatro, sin entender nunca por qué. Los cinco puntos de ruptura no son un marco aparte: son la metodología del apartado siguiente leída al revés, desde el síntoma, y sirven para diagnosticar un programa que ya está en marcha.
Metodología integral de transformación: cuatro niveles, del diagnóstico a la verificación del valor
Si cada punto de ruptura necesita una disciplina distinta, una metodología completa tiene que organizarlas de modo que ninguna se quede fuera y que cada una intervenga en el momento en que es útil. La forma más clara de hacerlo es pensar la transformación en cuatro niveles: diagnosticar y decidir qué cambiar, diseñar el modelo futuro, implantarlo y conseguir que se adopte, y verificar el valor y aprender. Cada nivel tiene su propia pregunta, un responsable, unos entregables y una decisión explícita con la que termina, que alguien con autoridad tiene que tomar. La tabla y el diagrama que siguen son el mapa de todo el artículo.
| Nivel y pregunta | Quién responde | Entregables y herramientas | Decisión con la que termina |
| 1. Diagnosticar y decidir ¿Por qué cambiar y qué cambiar? Fases 0 y 1 | El patrocinador, con el directivo que responderá del beneficio | Problema formulado sin nombrar la solución, línea base, caso de transformación en una página, inventario de controles informales y lista de supuestos | Diseñar, mejorar lo actual o no hacer nada |
| 2. Diseñar el modelo futuro ¿Cómo será el trabajo, quién decidirá y con qué? Fase 2 | Los propietarios de los procesos afectados, con el responsable de la transformación | Procesos de punta a punta sobre el trabajo real, matriz de derechos de decisión, niveles de autonomía de la IA, incentivos y las cuatro pruebas de diseño | Construir, rediseñar o abandonar |
| 3. Implantar y adoptar ¿Cómo se construye y cómo se consigue que funcione? Fases 3 y 4 | El responsable de la transformación; cada mando, de la adopción en su equipo | Solución probada, piloto con grupo de comparación, diagnóstico ADKAR por colectivos, registro de objeciones y plan de marcha atrás | Escalar, posponer o reducir el alcance |
| 4. Verificar el valor y aprender ¿Ha mejorado de verdad la empresa? Fase 5 | El dueño del beneficio, ante el comité de dirección | Cuadro de mando de tres capas con contraindicadores, valor económico capturado y revisión de supuestos | Consolidar, ajustar, rediseñar o revertir |
Una tabla de cuatro niveles invita a leerla como una cascada, en la que primero se diagnostica todo, después se diseña todo y al final se implanta todo. No es así como funciona una transformación bien dirigida, y conviene desactivar esa lectura desde el principio. Los niveles se solapan y se repiten: un piloto pertenece al tercer nivel, pero su propósito principal es producir evidencia para el cuarto, y esa evidencia sirve para corregir el segundo. En una implantación por oleadas, la primera oleada puede estar ya en verificación mientras la tercera sigue en diseño. Lo que no se solapa ni se omite son las decisiones con las que termina cada nivel: alguien tiene que decidir explícitamente seguir, ajustar o parar, y tiene que hacerlo con evidencia.
Las flechas de vuelta son lo que distingue esta metodología de un plan de proyecto con más fases. Los resultados del cuarto nivel pueden obligar a revisar la implantación, que es lo que todo el mundo acepta, pero también el propio diseño, que es lo que casi nadie quiere oír cuando ya se ha invertido mucho. En la empresa del ejemplo, la flecha corta habría llevado a formar mejor a los empleados en la gestión de excepciones. La flecha larga habría llevado a una conclusión más incómoda y más útil: que el sistema se había diseñado sobre el procedimiento oficial y no sobre el trabajo real, y que había que rediseñar el reparto de tareas entre personas y tecnología. Una metodología que no prevé la flecha larga obliga a la organización a seguir implantando mejor un diseño que ya ha demostrado ser equivocado.
Los cuatro niveles se apoyan en las tres disciplinas descritas antes y en una cuarta capacidad que las atraviesa a todas: la evaluación continua del valor generado y la disposición a corregir las decisiones iniciales. Esa cuarta capacidad no pertenece a un departamento, sino a la forma de gobernar el programa, y su prueba más sencilla es preguntar si alguna vez se ha detenido o reducido una iniciativa porque los datos así lo aconsejaban. Si la respuesta es que nunca, no significa que todas las decisiones fueran buenas, sino que no existe el mecanismo para descubrir las malas. Los apartados que siguen recorren los cuatro niveles en orden, empezando por el que más a menudo se salta: la decisión de si merece la pena cambiar.
Conviene dejar clara desde aquí la arquitectura del método, para que no se confunda con una colección de listas. Hay una sola estructura: las cinco preguntas dicen qué hay que resolver, los cuatro niveles ordenan cómo resolverlo y las seis fases de la hoja de ruta los ponen en el calendario. Todo lo demás son herramientas al servicio de un nivel concreto: la plantilla del caso de transformación y el inventario de controles sirven al primero; las pruebas de diseño y la matriz de decisión, al segundo; el diagnóstico por colectivos y el registro de objeciones, al tercero; el cuadro de mando y la revisión de supuestos, al cuarto. Las preguntas para el comité del final no añaden nada nuevo: son los cuatro niveles convertidos en lo que hay que exigir antes de cada decisión.
Caso de transformación: cómo comparar el coste de seguir igual con el riesgo de cambiar mal
La inmovilidad tiene costes reales, aunque rara vez aparezcan en una partida diferenciada de la cuenta de resultados. Procesos manuales, duplicidad de datos, decisiones lentas, sistemas obsoletos, errores recurrentes, experiencias deficientes de cliente y dificultades para crecer consumen recursos todos los días. No cambiar no es una posición neutral: es una decisión activa cuyo coste se paga en tiempo perdido, en decisiones lentas y en oportunidades que nunca llegan a materializarse. La deuda técnica y organizativa se acumula en silencio, y cuando por fin se hace visible suele ser porque un competidor ha conseguido hacer en dos días lo que a la empresa le cuesta cinco.
Pero hay dos errores simétricos, y el segundo es tan frecuente como el primero. El primero es no cambiar porque el funcionamiento actual resulta familiar y sus costes se han normalizado. El segundo es cambiar precipitadamente porque una tecnología está de moda, porque un competidor ha anunciado que la utiliza o porque el consejo pregunta qué se está haciendo con la inteligencia artificial. La urgencia de una transformación tiene que construirse sobre evidencia, no sobre ansiedad, porque la ansiedad elige soluciones antes de haber entendido el problema.
Qué debe cuantificar el diagnóstico antes de aprobar una inversión
Un buen caso de transformación cuantifica, en la medida de lo posible, seis cosas. Por el lado del modelo actual, el coste operativo y el desperdicio; las incidencias, los retrabajos, los errores, las reclamaciones y los riesgos; las demoras en las decisiones y las oportunidades comerciales perdidas; las limitaciones para crecer, innovar o responder a nuevas exigencias; y el coste de oportunidad de mantener a personas cualificadas en tareas de bajo valor. Por el lado del modelo propuesto, la inversión, el riesgo de la transición, la curva de aprendizaje y las pérdidas potenciales. Esta última partida es la que casi siempre falta, porque nadie quiere presentar al comité lo que el cambio puede romper.
La cuantificación sirve, sobre todo, para descomponer el problema antes de elegir la solución. Una empresa que tarda cinco días en resolver una solicitud puede aspirar a resolverla en dos. Antes de comprar un sistema nuevo conviene averiguar qué origina los otros tres: si son esperas entre departamentos, datos incompletos, aprobaciones innecesarias, un cuello de botella de capacidad o decisiones mal delegadas. Si el problema es un circuito de autorizaciones absurdo, digitalizarlo con gran entusiasmo solo conseguirá que la burocracia circule a mayor velocidad. Y si el retraso se concentra en una espera de cuarenta y ocho horas entre dos áreas, acelerar las tareas que se hacen antes y después de esa espera apenas moverá el plazo total, por mucho que la herramienta sea espectacular. Es lo que demostró Gene Amdahl hace más de medio siglo para los ordenadores: la mejora total está limitada por la fracción del tiempo que ocupa la parte que se acelera.
Por último, la alternativa a cambiar no es automáticamente peor, y debe compararse con las alternativas reales de cambio, no con un statu quo caricaturizado. Casi siempre existen al menos tres: no hacer nada, mejorar de forma gradual el modelo actual y transformarlo. Una transformación se justifica cuando su valor neto esperado, considerando costes, riesgos y capacidades, supera razonablemente al de las otras dos opciones, y no simplemente cuando supera al de no hacer nada. Comparar solo con la inacción es la manera más habitual de que cualquier proyecto parezca rentable.
Plantilla del caso de transformación en una página, aplicada a la empresa del ejemplo
Para que la herramienta sea concreta, conviene darle cuerpo a la empresa de la introducción. Supongamos que se dedica al mantenimiento técnico de edificios, comunidades de propietarios y pequeñas empresas, que tiene unas 450 personas en atención y planificación, y que gestiona alrededor de 60.000 solicitudes al mes, desde una avería de ascensor hasta la revisión anual de una caldera. Las cifras que siguen son ilustrativas y no proceden de ningún caso real. La tabla muestra lo que su caso de transformación debería haber contenido antes de comprar la plataforma de IA, y lo que en realidad contenía.
| Campo | Qué debe contener | Lo que debería haber dicho en la empresa del ejemplo |
| Problema y causa | El problema de negocio, no la solución, y sus causas comprobadas | La resolución media tarda cinco días; el 60 % de ese tiempo es espera de piezas, de aprobación o de un técnico, no tiempo de atención |
| Línea base | Los indicadores actuales medidos con el mismo método que se usará después | Plazo de resolución, reaperturas, resolución al primer contacto, coste por gestión y quejas, por tipo de caso, durante tres meses |
| Coste de seguir igual | Lo que se pierde cada año si no se hace nada | Penalizaciones por incumplir plazos con clientes corporativos y pérdida de contratos de comunidades en la renovación |
| Alternativas comparadas | Al menos tres opciones, incluida una mejora gradual | Rediseñar el circuito de aprobaciones y piezas; automatizar la clasificación; plataforma de IA completa |
| Valor esperado y supuestos | Cuánto, cuándo y bajo qué hipótesis, con los supuestos escritos | Reducir el plazo a tres días si la espera de aprobación baja a la mitad; la IA ahorra tiempo de atención, no de espera |
| Destino de la capacidad liberada | Qué se hará con el tiempo que se libere, quién lo decide y cómo se convertirá en dinero | Absorber el crecimiento previsto de contratos sin ampliar plantilla y reducir las horas extra de los picos de invierno |
| Coste y riesgo de cambiar | Inversión, transición, curva de aprendizaje y pérdidas posibles | Licencias e integración, seis meses de productividad reducida, riesgo de errores en casos con garantía o seguro |
| Capacidades que se pueden perder | Conocimiento, controles y relaciones que dependen del trabajo actual | El criterio de los coordinadores veteranos para detectar averías recurrentes y clientes en riesgo de baja |
| Criterios para parar o rediseñar | Qué resultado, en qué plazo, haría detener o cambiar la iniciativa | Si a los seis meses las reaperturas suben más de dos puntos o el plazo de casos complejos empeora, se revisa el diseño |
La comparación de las dos columnas explica casi todo lo que le ocurrió después a la empresa. Su caso de negocio real tenía una sola línea de valor, el ahorro de tiempo de atención por gestión, multiplicado por el número de gestiones. No tenía línea base por tipo de caso, no comparaba alternativas, no decía qué se haría con el tiempo ahorrado y no mencionaba las capacidades que se podían perder. Con ese documento, el proyecto no podía fracasar sobre el papel, y por eso nadie pudo ver a tiempo que estaba fracasando en la realidad. Si el análisis hubiera descubierto que el 60 % del plazo era espera, la primera alternativa, mucho más barata, habría aparecido como candidata seria, y la plataforma de IA se habría diseñado para un problema distinto.
Hay una última propiedad del caso de transformación que importa tanto como su contenido: no se firma una vez para olvidarlo. A lo largo del programa aparecerán datos que pueden invalidar las hipótesis iniciales, y cada uno debería actualizar el documento. Mantener la justificación de negocio vigente es tan importante como mantener actualizado el plan del proyecto, y quien responde de ella no es el director del proyecto, sino el directivo que responde del beneficio. Un buen hábito es revisarla formalmente en cada punto de decisión de la metodología, con la misma seriedad con la que se revisa el presupuesto.
Diagnóstico organizativo: cómo descubrir cómo funciona realmente el trabajo antes de elegir la solución
El mayor fallo metodológico de muchas transformaciones aparece antes de desarrollar nada: se elige la solución antes de comprender el problema. Es frecuente escuchar en un comité «necesitamos un CRM», «debemos implantar IA» o «hay que centralizar operaciones». Ninguna de esas frases describe todavía un problema de negocio; son hipótesis de solución, algunas razonables, pero hipótesis al fin y al cabo. Es la distinción que Richard Rumelt coloca en el centro de la buena estrategia: sin un diagnóstico que explique qué está pasando y por qué, los objetivos y las soluciones son solo deseos, como se explica en el artículo sobre buena y mala estrategia. El diagnóstico organizativo existe para convertirlas en lo que deberían haber sido desde el principio: preguntas sobre qué está fallando, por qué y cómo se sabrá si se ha corregido.
Análisis de causa raíz: cómo ir más allá del síntoma
Un aumento del tiempo de respuesta puede deberse a herramientas lentas, pero también a roles solapados, a procedimientos contradictorios, a una política comercial que genera excepciones o a un sistema de incentivos que penaliza la cooperación. Para distinguir síntomas de causas conviene utilizar técnicas de análisis causal adecuadas al problema: los cinco porqués, los diagramas de causa y efecto, el análisis de variación, Lean y Six Sigma cuando corresponda, o la minería de procesos cuando los sistemas registran los eventos de cada caso. La técnica importa menos que la disciplina de no aceptar la primera explicación plausible, que casi siempre es la que señala a la herramienta o a las personas.
Un ejemplo lo hace evidente. Los pedidos de una empresa se retrasan, y la solución inicialmente propuesta es automatizar el alta. El análisis, sin embargo, descubre que una parte importante de los retrasos surge porque el equipo comercial introduce condiciones especiales que Operaciones no puede cumplir sin una aprobación previa. El problema no es la velocidad del alta, sino la falta de reglas compartidas entre lo que se vende, la capacidad disponible y lo que se puede entregar. El rediseño tendrá que intervenir sobre la política comercial, la autoridad de decisión y el proceso de punta a punta. Automatizar el alta, en ese contexto, habría hecho llegar más deprisa a Operaciones pedidos que no podía cumplir.
Cómo documentar el trabajo real y no solo el procedimiento oficial
Un mapa de procesos suele mostrar cómo debería hacerse el trabajo. Para transformarlo hay que observar cómo se hace realmente, y eso exige un trabajo de campo que muchas consultoras recortan porque es lento y no luce en una presentación. Las fuentes son siempre las mismas: las personas que ejecutan, supervisan, reciben y sufren el proceso; los casos completos seguidos de principio a fin; y los datos que los sistemas dejan a su paso. Conviene entrevistar a los cuatro tipos de personas, seguir casos completos incluidos los excepcionales, analizar tiempos y transferencias entre departamentos con los registros de eventos cuando existan, e identificar las hojas de cálculo paralelas, los correos, los controles manuales y las consultas informales que sostienen el trabajo sin aparecer en ningún sitio. Toyota convirtió esta práctica en un hábito de dirección, ir a ver el trabajo donde ocurre antes de opinar sobre él, y es una de las piezas del sistema que se describe en la historia de Toyota.
Las preguntas de las entrevistas determinan lo que se descubre, y las más útiles no son las que preguntan cómo se hace el trabajo, porque esas obtienen como respuesta el procedimiento oficial. Las que funcionan preguntan por lo que se sale de la norma: qué ocurre cuando falla una herramienta, cuando falta un dato o cuando llega un caso que nadie había previsto; a quién se consulta cuando no se sabe qué hacer; qué comprobación se hace siempre aunque nadie la pida; qué error se ha cometido una vez y no se quiere repetir; qué caso se reconoce enseguida como problemático y por qué. Las respuestas a esas preguntas son el inventario del conocimiento que la organización tiene y no sabe que tiene.
Controles informales: cómo distinguir el desperdicio de la capacidad protectora
Este es probablemente el punto más crítico de todo el diagnóstico, y el que explica lo que le pasó a la empresa del ejemplo. En muchas organizaciones, una persona experimentada sabe que ciertos proveedores tienen registros incompletos, que determinadas solicitudes requieren una comprobación previa o que una excepción aparentemente menor anticipa un problema importante. El proceso oficial no refleja ese conocimiento, porque nunca se escribió. Cuando se automatiza el flujo documentado, los controles no documentados desaparecen en silencio, y su ausencia solo se descubre cuando aparecen los errores que evitaban.
Por eso, antes de eliminar una hoja auxiliar o un paso manual, es necesario determinar qué riesgo prevenía, si ese riesgo todavía existe y cómo quedará controlado en el modelo futuro. El objetivo no es conservar todas las costumbres, porque muchas son simplemente herencias sin valor, sino distinguir el desperdicio de la capacidad protectora. Una herramienta sencilla para hacerlo es un inventario de controles informales, con una fila por cada práctica no documentada que el trabajo de campo haya descubierto. En la empresa del ejemplo, ese inventario habría tenido filas como estas:
| Práctica informal | Quién la hace | Qué riesgo previene | Decisión para el modelo futuro |
| Hoja paralela de clientes con incidencias delicadas | Dos coordinadoras veteranas | Enviar a un técnico sin experiencia a un cliente a punto de darse de baja | El riesgo sigue existiendo: incorporar la marca de cliente en riesgo al sistema y a las reglas de asignación |
| Comprobar la garantía antes de asignar técnico | Atención, a mano | Facturar una reparación que debía cubrir el fabricante | El riesgo sigue existiendo: convertirla en validación automática antes de proponer la resolución |
| Llamar al cliente antes de cerrar una avería repetida | Algunos agentes, por iniciativa propia | Cerrar en falso una avería que volverá en una semana | El riesgo sigue existiendo: revisión humana a partir de la tercera incidencia en el mismo equipo en noventa días |
| Imprimir y firmar el parte de cierre | Planificación | Ninguno vigente; era un requisito de un contrato ya extinguido | El riesgo ya no existe: eliminar |
Lo instructivo de la tabla es su última fila. El inventario no sirve para conservarlo todo, sino para poder eliminar con tranquilidad lo que de verdad sobra y proteger lo que no. Una transformación que no hace este ejercicio tiene dos opciones, y las dos son malas: conservar todas las prácticas por miedo, y no transformar nada, o eliminarlas todas por eficiencia, y destruir capacidades sin saberlo.
Las cuatro dependencias que suelen olvidarse en un diagnóstico
Además de los controles informales, hay cuatro tipos de dependencia que casi ningún diagnóstico inventaría de forma sistemática, y que reaparecen después como incidencias tras el arranque. Las dependencias humanas responden a quién resuelve las excepciones, enseña a los nuevos, conecta áreas y detecta errores. Las organizativas, a qué departamento condiciona el trabajo de otro y dónde se acumulan decisiones sin dueño. Las tecnológicas y de datos, a qué sistemas alimentan el proceso y si son fiables sus integraciones, sus identificadores, sus permisos y sus fuentes maestras. Y las de gobierno, a quién puede aprobar una excepción, asumir un riesgo, detener una automatización o resolver un conflicto entre áreas.
Una quinta pregunta atraviesa las cuatro, y es la que más a menudo se olvida en las transformaciones con inteligencia artificial: qué capacidades estratégicas o qué conocimiento tácito podríamos perder si las personas dejan de ejecutar determinadas tareas. Muchas tareas aparentemente rutinarias cumplen una segunda función que nadie ha nombrado: son la forma en que los nuevos aprenden el oficio o en que los veteranos mantienen el criterio. Si se automatizan sin sustituir esa segunda función, la empresa ganará eficiencia hoy y perderá a los expertos que necesitará dentro de cinco años.
Sanear antes de acelerar: datos, integraciones y deuda técnica
Introducir un ERP, un CRM o una plataforma de agentes sobre datos contradictorios, integraciones frágiles, vulnerabilidades conocidas y deuda técnica no resuelta amplifica los problemas existentes. No hace falta renovar todo el legado antes de empezar, porque sería inviable para la mayoría de las empresas, pero sí definir un mínimo de preparación para cada caso de uso: integridad de los datos, controles de acceso, calidad de las interfaces, trazabilidad, soporte y planes de contingencia. La decisión práctica consiste en clasificar las deficiencias en tres grupos: las que bloquean el arranque; las que pueden corregirse durante el despliegue con controles temporales; y las que se aceptan conscientemente, con dueño, plazo y riesgo documentado. La remediación tecnológica tiene que formar parte del programa de transformación, con presupuesto y calendario propios, y no esconderse como trabajo incómodo para después.
Entregables del diagnóstico: qué debe existir antes de diseñar la solución
Al terminar esta etapa deberían existir, como mínimo, siete entregables: un problema de negocio formulado con precisión; una línea base de resultados medida por tipo de caso; un mapa de procesos de punta a punta que refleje el trabajo real; un inventario de dependencias y de controles formales e informales; una evaluación de capacidades, datos y tecnología; un mapa de interesados que distinga a quienes deciden de quienes ejecutan y de quienes sufren el proceso; y una lista explícita de los supuestos que todavía deben validarse. Si no se puede explicar con claridad qué está fallando, por qué y cómo se medirá la mejora, todavía no se está preparado para declarar que se ha encontrado la solución.
Diseño del modelo operativo futuro con Nadler-Tushman, sistemas sociotécnicos, Galbraith y McKinsey 7S
Una organización no se rediseña cambiando un organigrama y comprando una aplicación. Para que el resultado sea estable hay que ajustar a la vez las tareas, las capacidades, la estructura formal, las relaciones informales, las decisiones, los incentivos y las herramientas, porque cada una de esas piezas condiciona a las demás. Si se cambia una y se dejan las otras como estaban, las otras acaban devolviendo a la primera a su forma anterior. Es la razón por la que tantas implantaciones técnicamente correctas terminan reproduciendo, con herramientas nuevas, el funcionamiento de siempre.
No existe un único modelo que cubra todas esas dimensiones con la misma profundidad. Por eso conviene usar varios marcos complementarios como instrumentos de diagnóstico y de diseño, no como recetas que la empresa deba obedecer. Los cuatro que siguen se solapan en parte, pero cada uno obliga a mirar algo que los otros tienden a dejar fuera: Nadler-Tushman, las interdependencias entre lo formal y lo informal; el enfoque sociotécnico, el reparto del trabajo entre personas y tecnología; Galbraith, las palancas concretas de diseño; y McKinsey 7S, la coherencia del conjunto.
Modelo de congruencia de Nadler-Tushman: comprobar que encajan las partes de la organización
El modelo de congruencia que David Nadler y Michael Tushman formularon a principios de los años ochenta parte de una idea sencilla: el rendimiento de una organización depende de lo bien que encajan entre sí cuatro elementos interdependientes, que son el trabajo, las personas, la organización formal y la organización informal. Su aportación más valiosa para una transformación es que trata la organización informal como una pieza de diseño, al mismo nivel que el organigrama, y no como un ruido que hay que eliminar.
| Elemento | Pregunta de diseño | Riesgo típico en una automatización |
| Trabajo | ¿Qué tareas, secuencias y exigencias requiere el servicio? | Automatizar la tarea visible y olvidar las excepciones, los controles o la coordinación |
| Personas | ¿Qué habilidades, motivaciones y experiencia hacen falta? | Reducir puestos sin preservar el criterio y el conocimiento operativo |
| Organización formal | ¿Qué funciones, autoridad, procesos y reglas se necesitan? | Dejar ambiguos las responsabilidades y los derechos de decisión |
| Organización informal | ¿Qué redes de confianza, ayuda y prácticas no escritas sostienen la actividad? | Romper mecanismos que resolvían problemas que el procedimiento nunca describió |
El objetivo no es que cada elemento funcione bien por separado, sino que encajen entre sí, y los desajustes se reconocen con facilidad en cuanto se buscan. Si una IA propone resoluciones más rápidas, pero el marco de autorizaciones obliga a validarlas en tres escalones, el beneficio no aparecerá. Si se simplifica la jerarquía sin crear capacidades de supervisión adecuadas, crecerán los riesgos. Y si se elimina una tarea rutinaria que servía para formar especialistas, habrá que crear otra forma de desarrollar esa experiencia, o la empresa se quedará sin especialistas dentro de unos años. En la empresa del ejemplo, la red informal de consultas a las coordinadoras veteranas era la pieza que sostenía la resolución de los casos complejos, y el nuevo diseño la eliminó sin sustituirla.
Sistemas sociotécnicos: diseñar a la vez la tecnología y el trabajo
La investigación sociotécnica nació en 1951, cuando Eric Trist y Ken Bamforth, del Tavistock Institute de Londres, estudiaron lo que había ocurrido en las minas de carbón británicas al introducir un método de extracción mecanizado. La nueva tecnología era más productiva sobre el papel, pero rompió los pequeños equipos autónomos que se repartían el trabajo y se cubrían entre sí, y lo sustituyó por tareas fragmentadas en turnos. El resultado fue más absentismo, más conflictos y una productividad inferior a la prevista. Su lección sigue intacta setenta años después: optimizar técnicamente una actividad no garantiza optimizar el sistema de trabajo del que forma parte.
La consecuencia práctica es cambiar la pregunta con la que se diseña. La pregunta habitual es qué puede automatizar la herramienta. La pregunta sociotécnica es cómo deberían repartirse las actividades y las decisiones entre personas y tecnología para obtener el mejor resultado global. La diferencia parece pequeña, pero la primera optimiza la herramienta y la segunda optimiza el servicio. Una plataforma puede clasificar reclamaciones automáticamente, pero ese beneficio no se materializará si crea categorías que los equipos no entienden, si deriva mal las excepciones o si impide explicar una decisión al cliente. La calidad del sistema depende tanto de la precisión del modelo como del diseño de los circuitos humanos que lo rodean.
En la práctica, un diseño sociotécnico se reconoce porque responde explícitamente a cinco preguntas que un diseño puramente técnico deja abiertas: qué parte de cada decisión toma la tecnología y qué parte la persona; cómo se entera la persona de que la tecnología se ha equivocado; qué margen tiene para corregirla sin pedir permiso; cómo mantiene el criterio que necesita para hacerlo si ya casi nunca practica la tarea; y quién aprende de los errores para mejorar el sistema. Si el diseño no puede responder a la segunda y a la cuarta, la organización está construyendo una dependencia, no una colaboración.
Star Model de Galbraith: las cinco palancas del diseño organizativo
El Star Model de Jay Galbraith conecta cinco decisiones de diseño que tienen que ser coherentes entre sí. La estrategia define qué valor quiere ofrecer la organización y dónde quiere competir. La estructura decide dónde reside la autoridad y cómo se reparten las responsabilidades. Los procesos determinan cómo fluyen el trabajo, la información y las decisiones entre unidades. Las recompensas establecen qué indicadores, reconocimientos e incentivos orientan el comportamiento. Y las personas concretan qué perfiles, competencias, selección, formación y desarrollo harán falta. Su utilidad principal es que convierte la abstracción del diseño organizativo en cinco decisiones concretas que alguien tiene que tomar y firmar.
El caso más habitual de incoherencia entre palancas es también el más ilustrativo. Imaginemos una empresa que quiere que Atención, Ventas y Operaciones compartan la responsabilidad sobre el cliente. Para conseguirlo implanta un CRM común, redefine los procesos para que la información fluya entre las tres áreas y organiza sesiones de formación conjuntas. Pero cada director sigue siendo evaluado y premiado exclusivamente por el resultado de su propio departamento. Los nuevos procesos transversales competirán con el sistema real de incentivos, y la empresa habrá construido colaboración en la presentación y competencia interna en la vida diaria. Galbraith obliga a hacerse la pregunta que habría evitado el problema: si cambiamos los procesos, ¿qué palanca de recompensa los sostiene?
McKinsey 7S: comprobar el alineamiento interno de la organización
El modelo 7S, desarrollado en McKinsey a finales de los años setenta por Tom Peters, Robert Waterman y Julien Phillips, amplía la revisión organizativa a siete elementos: la estrategia (strategy), la estructura (structure), los sistemas y procesos (systems), las capacidades (skills), las personas y su dotación (staff), el estilo de liderazgo (style) y los valores compartidos (shared values). Recuerda algo que cualquier transformación tiende a olvidar: el cambio no se implanta en una sola palanca, y cualquier cambio real afecta también a las capacidades, al estilo de los mandos y a lo que la organización cree.
Su utilidad principal es detectar incoherencias, y algunas de las habituales se reconocen en cuanto se nombran: una estrategia de servicio excelente con incentivos centrados exclusivamente en el volumen; equipos formados para colaborar bajo un liderazgo que penaliza compartir información; tecnologías modernas sostenidas por datos sin dueño o por procedimientos antiguos; o una apuesta decidida por la inteligencia artificial sin las capacidades necesarias para gobernarla. Lo que 7S no hace es diseñar las soluciones: una lista de dimensiones bien revisada dice dónde está el desajuste, pero no cómo corregirlo.
Las cuatro pruebas de diseño: cómo combinar los marcos sin convertirlos en ceremonias
Galbraith ayuda a tomar decisiones concretas de diseño; 7S permite comprobar si el conjunto de la organización está alineado; Nadler-Tushman obliga a mirar las interdependencias formales e informales; y el enfoque sociotécnico ordena el reparto del trabajo entre personas y tecnología. Hay solapamientos, naturalmente. No tiene sentido aplicar los cuatro como cuatro talleres separados que producen cuatro documentos; lo que tiene sentido es elegir, para cada decisión de diseño, la perspectiva que descubre los problemas que todavía no se habían visto.
Una forma práctica de hacerlo es usar cada marco como una prueba de una sola pregunta sobre el diseño propuesto. La prueba de Galbraith es si cada cambio de proceso tiene una recompensa que lo sostenga. La de Nadler-Tushman, qué mecanismo informal desaparece con el nuevo diseño y qué lo sustituye. La sociotécnica, cómo se entera la persona de que la tecnología se ha equivocado. Y la de 7S, qué elemento de los siete quedará exactamente igual que antes y si eso es compatible con lo demás. Son cuatro preguntas que caben en una página y que, hechas a tiempo, habrían sacado a la luz antes del arranque varios de los problemas que la empresa del ejemplo descubrió después.
Derechos de decisión, propietarios de proceso y excepciones: lo que el diseño no puede dejar ambiguo
De todo lo que se diseña en una transformación, lo que con más frecuencia queda sin concretar es quién decide qué. Se dibujan procesos, se definen roles y se configuran sistemas, pero la pregunta de quién tiene la última palabra en cada decisión se deja para más adelante, con la esperanza de que el sentido común la resuelva. No la resuelve: la ambigüedad sobre las decisiones es la causa más directa de que, cuando surge una excepción, nadie sepa con certeza quién debe actuar. Es exactamente el síntoma con el que empezaba la empresa del ejemplo.
Antes de implantar el modelo futuro hay que concretar siete cuestiones. La primera es la propiedad de cada proceso de punta a punta, es decir, quién responde del resultado aunque participen varias áreas. La segunda, los derechos de decisión: qué puede decidir un empleado, un supervisor, un sistema automatizado y un comité. La tercera, las reglas de escalado y de excepción, con sus tiempos y las evidencias que requieren. La cuarta, las capacidades que deben preservarse aunque una tarea se automatice. La quinta, la información y la tecnología: cuál será la fuente fiable de cada dato, cómo se integrarán los sistemas y quién controla los cambios. La sexta, los controles y riesgos: qué salvaguardas se mantienen, cuáles se sustituyen y cómo se prueba su eficacia. Y la séptima, la que casi siempre falta, es la responsabilidad sobre los beneficios: qué directivo responde de que aparezcan los resultados después de la puesta en marcha.
Matriz de derechos de decisión: una herramienta para repartir decisiones entre personas y sistemas
La herramienta más útil para resolver la segunda y la tercera cuestión es una matriz de derechos de decisión: una fila por cada decisión relevante del proceso y, en cada fila, quién la ejecuta, quién la decide y responde de ella, y a quién hay que consultar o informar. Los marcos más conocidos para construirla son RACI, DACI y RAPID, y la elección entre ellos importa menos que dos reglas de uso. La primera regla es que cada fila tiene un único decisor; la segunda, que quien ejecuta y quien responde se escriben por separado, porque un sistema puede ejecutar una decisión, pero quien responde de ella es siempre una persona con nombre. En la empresa del ejemplo, la matriz rediseñada para la atención de solicitudes podría tener esta forma:
| Decisión | Quién la ejecuta | Quién decide y responde | A quién se consulta o informa |
| Clasificar una solicitud estándar | La plataforma de IA, sin revisión previa | El propietario del proceso de atención, que fija las reglas y responde de la calidad de la clasificación | El agente la corrige si detecta un error; la supervisión revisa una muestra semanal |
| Proponer la resolución | La plataforma, con su justificación | El agente de atención, que la acepta, la modifica o la rechaza | — |
| Compensar al cliente hasta 150 € | El agente de atención | El agente de atención | Se informa a la supervisión |
| Compensar al cliente por encima de 150 € | El agente, una vez aprobada | La supervisión, en un plazo máximo de cuatro horas | El propietario del proceso recibe el resumen mensual |
| Tercera avería en el mismo equipo en noventa días | La plataforma la detecta y avisa | La supervisión, que decide la intervención | Se consulta al coordinador veterano de la zona |
| Detener una automatización por errores | La supervisión de turno | La supervisión de turno, sin pedir permiso | Se informa de inmediato al propietario del proceso y al responsable técnico |
| Reanudar la automatización | El responsable técnico de la plataforma | El propietario del proceso, una vez analizada la causa | Se consulta a la supervisión que la detuvo |
La primera fila muestra cómo se aplica la segunda regla. La plataforma clasifica sola, pero quien responde de que la clasificación sea correcta es el propietario del proceso, que fija las reglas, recibe los resultados de la muestra semanal y decide cuándo subir o bajar el nivel de autonomía de esa acción. Las dos últimas filas suelen faltar en los diseños, y conviene que sean dos y no una. Toda automatización necesita a alguien con autoridad para detenerla cuando produce errores, y esa autoridad tiene que estar cerca de la operación, porque es allí donde se detectan los errores y cada hora de espera los multiplica. Reanudarla es otra decisión, con otro responsable: exige entender qué falló y comprobar que se ha corregido, y la toma el propietario del proceso, que responde del resultado de punta a punta.
Dos detalles de construcción hacen que la matriz funcione en la práctica. El primero es fijar umbrales concretos en lugar de criterios genéricos: «hasta 150 euros» se aplica igual por todo el mundo, mientras que «compensaciones razonables» se interpreta de cuarenta maneras. El segundo es asociar a cada escalado un plazo máximo de respuesta, porque una decisión que se escala y nadie contesta se convierte en una espera más del proceso. La responsabilidad no puede diluirse detrás de frases como «el sistema lo ha decidido» o «eso pertenece a otro departamento», y la matriz es el documento que impide que lo haga. El artículo sobre cómo arrancar un proyecto de transformación desarrolla el marco RAPID y la idea de un único decisor con plazo de respuesta para las decisiones del propio programa.
Cultura organizativa, liderazgo e incentivos: por qué la organización defiende el modelo anterior
La cultura organizativa es el conjunto de creencias, valores, comportamientos y reglas no escritas que determinan cómo se hacen realmente las cosas dentro de una empresa. No consiste en lo que aparece en la web corporativa ni en la presentación de valores de la convención anual. Se manifiesta en las decisiones que se toman, en los comportamientos que se toleran, en las personas que progresan, en los conflictos que se evitan y en los resultados que de verdad se recompensan. Por eso cambiarla es mucho más difícil de lo que parece: la cultura no se modifica por lo que se comunica, sino por lo que las personas experimentan en su día a día.
Las personas observan constantemente. Observan si los líderes actúan de forma coherente con lo que dicen, si las decisiones reflejan los nuevos valores y si los sistemas de reconocimiento premian los comportamientos que se dice querer impulsar. Un discurso de colaboración no cambia nada si la carrera profesional sigue dependiendo de proteger información. Una declaración de innovación resulta poco creíble cuando reconocer un error tiene consecuencias negativas. Y pedir iniciativa a los empleados mientras se les exige autorización para cualquier excepción les enseña muy deprisa cuál es la verdadera regla del juego.
Edgar Schein, una de las referencias clásicas en este campo, describió con precisión cómo los líderes moldean esa regla del juego: mediante aquello a lo que prestan atención y miden, cómo reaccionan ante las crisis y los errores, cómo asignan los recursos, a quién reconocen y con qué criterios contratan, promocionan o separan a las personas. Ninguno de esos mecanismos es un mensaje; todos son decisiones, y por eso pesan mucho más que cualquier comunicación. La frase que se atribuye habitualmente a Peter Drucker, que la cultura se come a la estrategia en el desayuno, no significa que la estrategia no importe. Significa que una estrategia brillante no sobrevive si entra en conflicto con los hábitos, los incentivos, los miedos y las rutinas reales de la organización: la estrategia marca el rumbo, y la cultura decide la velocidad y la capacidad de sostener el esfuerzo cuando aparecen las dificultades.
Cómo convertir los valores en comportamientos observables y reforzarlos
Una de las definiciones más prácticas de cultura es la que propone Simon Sinek: la cultura es la suma de los valores y los comportamientos. Los valores solo tienen utilidad cuando dejan de ser conceptos abstractos y se convierten en acciones concretas. La integridad no es una palabra, sino hacer lo correcto; la honestidad es decir la verdad; la innovación es buscar una forma nueva de resolver un problema. Solo los comportamientos pueden observarse, repetirse, evaluarse y convertirse en un estándar compartido, y por eso una transformación cultural empieza por traducir cada valor a conductas y cada conducta a un mecanismo de gestión que la refuerce.
| Valor declarado | Comportamiento observable | Refuerzo de gestión |
| Colaboración | Resolver incidencias transversales sin devolverlas entre áreas | Indicador compartido de resolución de punta a punta |
| Aprendizaje | Comunicar errores pronto y documentar lo aprendido | Revisiones de incidentes sin búsqueda automática de culpables |
| Orientación al cliente | Evaluar el impacto real antes de cerrar una tarea | Medir el resultado para el cliente, no solo la actividad interna |
| Responsabilidad | Identificar al decisor y justificar las excepciones | Roles claros, seguimiento y reconocimiento |
| Innovación | Probar mejoras con hipótesis y límites definidos | Tiempo reservado para experimentar y evaluación de beneficios |
Definir los comportamientos no basta. La cultura se construye cuando la organización los incentiva de forma coherente y, sobre todo, cuando quienes mejor los representan son reconocidos y promovidos a posiciones de liderazgo. Cada promoción, cada reconocimiento y cada decisión sobre el desempeño envían un mensaje más potente que cualquier declaración de valores. Un único ascenso de una persona con resultados extraordinarios y comportamientos tóxicos puede enseñar más sobre la cultura de una empresa que decenas de talleres sobre valores. Del mismo modo, cuando los sistemas de evaluación solo premian los resultados, las personas aprenden que los números importan más que la forma de conseguirlos.
Cuando los nuevos comportamientos empiezan a funcionar, se activa un círculo virtuoso: generan pequeños éxitos, los éxitos se reconocen, el reconocimiento refuerza la credibilidad y la credibilidad anima a más personas a sumarse. En ese proceso, los referentes informales de los equipos juegan un papel decisivo, porque son ellos quienes, con su experiencia cotidiana, validan o desacreditan el cambio ante sus compañeros. Incorporar a esas personas al diseño y a las pruebas no es una táctica de comunicación, sino una inversión en la calidad de la solución, porque suelen ser también las que mejor conocen el trabajo real.
Liderazgo de la transformación: lo que el patrocinador tiene que hacer y no puede delegar
Una transformación necesita un liderazgo visible y sostenido, y el problema rara vez está en la tecnología, sino en la falta de propiedad real, de claridad estratégica y de disciplina en la ejecución. Es la tesis de Tony Saldanha en Why Digital Transformations Fail, y cualquiera que haya trabajado en un programa grande la reconoce. Patrocinar no es inaugurar el programa ni aparecer en el vídeo de lanzamiento, sino hacer seis cosas que solo puede hacer quien tiene el poder para hacerlas: elegir prioridades y renunciar a las iniciativas incompatibles; resolver los conflictos entre departamentos y asumir su coste político; asignar presupuesto y capacidad efectiva, no recursos imaginarios que siguen dedicados a su trabajo anterior; cambiar los indicadores y las recompensas que contradicen el nuevo modelo; proteger a quienes revelan problemas y hacen propuestas fundamentadas; y practicar personalmente los comportamientos que exige a los demás. La primera de esas tareas, elegir y renunciar, es la que mejor ilustra la transformación de LEGO: la recuperación de la compañía a partir de 2004 no empezó añadiendo iniciativas, sino recortando la variedad de productos y de piezas y concentrando los recursos en el negocio que de verdad creaba valor.
Si se impulsa un modelo transversal, pero cada decisión controvertida termina favoreciendo los intereses de un silo, la plantilla aprenderá pronto que la transformación es opcional. Y si los líderes no cambian lo que miden, lo que permiten y lo que recompensan, el resto de la organización no tiene ningún motivo para cambiar lo que hace. Liderar una transformación no consiste en pedir a los demás que cambien, sino en empezar por cambiar las reglas que el propio liderazgo controla. En la empresa del ejemplo, el indicador que la dirección revisaba cada semana era el porcentaje de gestiones que pasaban por la plataforma, y la organización entera se orientó, con toda lógica, a maximizarlo. Las exigencias que una transformación impone al estilo de cada directivo, y el momento en que un estilo útil se vuelve dañino, se analizan en el artículo sobre los ocho estilos de liderazgo.
Resistencia al cambio: cómo investigar si una objeción señala un fallo del diseño o defiende un interés
Buena parte de la literatura sobre gestión del cambio habla de la resistencia con un vocabulario de batalla: combatir las inercias, vencer la resistencia, eliminar las barreras que representan determinados mandos. Ese lenguaje tiene sentido cuando la oposición responde a intereses particulares o a comportamientos disfuncionales, que existen y hay que afrontar. Pero tiene un efecto secundario grave: convierte cualquier objeción en un problema de actitud, y hace que la organización deje de escuchar precisamente a quienes podrían advertirle de un error.
La realidad es más variada. Algunas personas se oponen porque temen perder estatus, control, comodidad o empleo. Otras porque han vivido iniciativas fallidas y no creen las promesas, lo que no es irracional sino aprendizaje. Otras simplemente no entienden el cambio o no saben aplicarlo. Y existen también las objeciones técnicamente acertadas: empleados que ven una dependencia oculta, un riesgo de calidad, una pérdida de conocimiento o una decisión de negocio mal fundamentada. Un empleado que se opone a automatizar una actividad puede estar defendiendo un privilegio, pero también puede estar identificando un riesgo que la dirección desconoce. La diferencia tiene que descubrirse mediante diagnóstico; no puede presumirse.
Las cuatro lecturas de la resistencia y la respuesta que exige cada una
Una forma útil de ordenar la resistencia es distinguir cuatro lecturas posibles de cada objeción. Pueden darse a la vez en la misma persona, y cada una exige una respuesta distinta; aplicar la equivocada es peor que no responder, porque confirma a quien objeta que no se le ha escuchado. La tabla sirve para formular hipótesis sobre cada objeción antes de decidir qué hacer con ella, no para etiquetar a quien la plantea.
| Lectura | Qué la causa | Señal que sugiere esta lectura | Respuesta adecuada |
| No entiende o no sabe | Falta de conciencia, conocimiento o práctica | La objeción desaparece cuando se explica o se practica con casos reales | Explicar el porqué, formar con casos reales y acompañar en el puesto |
| Defiende un interés | Pérdida de estatus, control, comodidad, ingresos o empleo | Los argumentos cambian cuando se responde al anterior y la conclusión se mantiene | Reconocer el interés, negociar lo negociable y decidir con transparencia lo que no lo es |
| Desconfía por experiencia | Iniciativas anteriores que prometieron y no cumplieron | Acepta el diagnóstico, pero duda de que la dirección vaya a sostener el cambio | Demostrar con hechos verificables y cumplir los compromisos pequeños |
| Ha detectado un fallo | Un riesgo, una dependencia o una pérdida de capacidad que el diseño no contempla | La objeción es concreta, se puede comprobar y se sostiene cuando se pide un ejemplo | Investigar, y si se confirma, corregir el diseño y reconocer públicamente la aportación |
Ninguna de esas señales es una prueba. Que alguien cambie de argumento cada vez que se responde al anterior puede indicar que defiende un interés, pero también que ha percibido un problema real que no sabe formular con precisión, algo habitual en quien conoce el trabajo por experiencia y no por el procedimiento. Por eso las cuatro lecturas son hipótesis que se investigan, nunca criterios suficientes para etiquetar a una persona, y se aplican a cada objeción, no a quien la plantea. La forma de contrastarlas es la misma en todos los casos: pedir un ejemplo concreto, comprobarlo en los datos o en un caso real y ver qué queda en pie. Lo que conviene evitar es la alternativa habitual, que consiste en suponer de entrada que toda oposición pertenece a la segunda lectura.
Registro de objeciones documentadas: cómo convertir la resistencia en información para el proyecto
Una buena práctica, sencilla y poco habitual, consiste en establecer un canal de objeciones documentadas con un registro tan formal como el de riesgos del proyecto. Cada objeción se anota con cinco campos: qué riesgo se denuncia, qué evidencia lo sostiene, quién debe evaluarlo y en qué plazo, cuál es la decisión y cómo se comunica a quien la planteó. La dirección no tiene obligación de aceptar todas las objeciones, pero sí de escucharlas y de responder con argumentos. La participación no es un referéndum sobre cada detalle, y tampoco debe reducirse a persuadir a los empleados para que acepten decisiones intocables.
En la empresa del ejemplo, ese registro habría cambiado la historia. Durante el piloto, una de las coordinadoras veteranas advirtió de que la plataforma clasificaba como estándar las averías repetidas, y que así se perdería la llamada previa al cierre con la que ella detectaba los equipos que había que sustituir. Su objeción se interpretó como resistencia, se le explicó de nuevo el funcionamiento del sistema y se anotó como un problema de deseo. Seis meses después, las reaperturas por averías repetidas eran la primera causa de retrabajo, y la solución consistió exactamente en lo que ella había propuesto. Una objeción documentada es un dato del proyecto; tratarla como un problema de actitud es desperdiciar el sistema de alerta más barato que tiene la organización.
Nada de esto significa que la dirección deba renunciar a decidir. Hay resistencias que responden a intereses legítimos en conflicto con el interés general de la empresa, y ahí lo correcto es reconocer el conflicto, compensar lo que pueda compensarse y decidir con claridad. Lo que distingue una transformación bien dirigida no es que no imponga nada, sino que sabe qué está imponiendo, a quién y por qué, y que no confunde la imposición de una decisión con la demostración de que era correcta.
Modelo de Kotter: los ocho pasos aplicados a una transformación y el error típico de cada uno
Una vez que existe una dirección de transformación razonablemente fundamentada, empieza otro problema: movilizar a la organización, construir las nuevas capacidades y conseguir que el sistema diseñado sea el sistema utilizado. Aquí los modelos clásicos de gestión del cambio aportan mucho, y el error no está en usarlos, sino en pedirles que decidan cuestiones estratégicas o de arquitectura organizativa para las que no fueron concebidos. Este apartado y los dos siguientes no los explican por sí mismos, sino por lo que aportan al tercer nivel de la metodología y por el punto exacto en que se quedan cortos. El primero de ellos, y el más conocido, es el de John Kotter.
Kotter parte de una idea que reconoce enseguida cualquiera que haya vivido una transformación de verdad: una organización no cambia porque se haya aprobado un plan, comprado una herramienta o comunicado una nueva prioridad en un comité. Cambia cuando la presión por moverse es real, cuando existe una dirección suficientemente clara, cuando los líderes empujan de forma consistente y cuando los equipos empiezan a ver que la nueva forma de trabajar no es una moda pasajera. Formuló su modelo en ocho pasos a mediados de los años noventa y, desde entonces, lo ha ido evolucionando desde una secuencia bastante lineal hacia un sistema de ocho aceleradores que pueden actuar a la vez. La tabla recoge los ocho en su versión actual, con su aplicación práctica y la deformación más habitual de cada uno.
| Paso | Aplicación práctica | Error que conviene evitar |
| 1. Crear sentido de urgencia | Mostrar con datos por qué el modelo actual es insuficiente y qué oportunidad se abre | Confundir urgencia con asustar a los empleados o amenazarlos con perder su puesto |
| 2. Construir una coalición guía | Integrar dirección, propietarios de procesos, mandos y referentes informales con credibilidad | Formar un comité de altos cargos sin influencia sobre la operación real |
| 3. Formular una visión estratégica | Describir qué cambiará para el negocio, el cliente y el trabajador, y qué permanecerá | Utilizar consignas vagas como «ser digitales» o «ser líderes en IA» |
| 4. Movilizar a un grupo amplio | Dar protagonismo a personas que puedan experimentar y promover el cambio | Tratar a toda la plantilla como receptora pasiva de instrucciones |
| 5. Eliminar barreras | Corregir obstáculos de organización, sistemas, permisos y decisiones | Llamar «resistente» al equipo que no puede trabajar por un impedimento estructural |
| 6. Generar victorias tempranas | Mostrar mejoras reales, verificadas y relevantes para el negocio | Celebrar actividades, demostraciones o licencias instaladas como si fueran beneficios |
| 7. Mantener la aceleración | Aprovechar los resultados para intervenir sobre problemas más profundos | Declarar el éxito definitivo después del primer piloto |
| 8. Institucionalizar el cambio | Incorporar las nuevas prácticas a roles, procesos, indicadores, incentivos y liderazgo | Convertir en permanente una solución que todavía no ha demostrado su valor |
La aportación de Kotter es política y organizativa, en el mejor sentido de las dos palabras. Entiende que cambiar una empresa implica movilizar intereses, crear una dirección compartida, vencer inercias y modificar los sistemas de gestión, y ofrece una secuencia práctica para hacerlo. Pero su marco no sustituye el análisis de viabilidad: se puede lograr una coalición entusiasmada, una visión inspiradora y numerosas victorias iniciales en un programa basado en una hipótesis de negocio equivocada. Kotter ayuda a mover la organización; no certifica por sí solo que el destino elegido sea el correcto.
Sentido de urgencia, victorias tempranas e institucionalización: los tres pasos que más se deforman
Tres de los ocho pasos merecen una advertencia especial, porque su versión deformada es la más extendida. El primero es la urgencia. Si la dirección presenta una tecnología como una amenaza existencial para el empleo de cada persona, puede obtener obediencia aparente, pero también silencio, ansiedad y ocultación de problemas, que es justo lo contrario de lo que necesita una transformación para corregirse. Es más sólido explicar el coste de no evolucionar, compartir las incertidumbres que todavía existen y mostrar oportunidades concretas que fabricar miedo. El miedo moviliza, pero moviliza hacia la autoprotección, no hacia la mejora.
El segundo son las victorias tempranas. Una victoria temprana no es una operación de relaciones públicas para silenciar a los críticos, y celebrarla con fuerza para sofocar las objeciones es la forma más rápida de que deje de ser creíble. Su función es ser evidencia de que la hipótesis funciona, y por eso solo cuenta como victoria lo que mejora un resultado de negocio medido contra una línea base: reducir un retrabajo concreto, acelerar una gestión sin generar defectos o eliminar una doble introducción de datos. Un informe automático que se genera en un clic es una demostración, no una victoria, salvo que alguien haya medido cuánto tiempo y cuántos errores ahorra.
El tercero es la institucionalización, y aquí aparece una paradoja que el modelo no resuelve por sí solo. Kotter insiste con razón en que el error cumbre es declarar el triunfo en cuanto termina el despliegue y en que el cambio tiene que anclarse en la cultura para no desvanecerse. Pero si se institucionaliza un cambio equivocado, lo que se ancla en la cultura es un problema, y deshacerlo después costará más que haberlo evitado. Por eso, en esta metodología, el octavo paso está condicionado a la evidencia de creación de valor del cuarto nivel, y no a la adopción.
Modelo ADKAR y metodología Prosci: cómo diagnosticar por colectivos dónde se bloquea la adopción
Si Kotter mira la organización en su conjunto, el modelo ADKAR, desarrollado por Jeff Hiatt y difundido por Prosci, desplaza el foco hacia la persona concreta que tiene que modificar su forma de trabajar. Las empresas no cambian; cambian las personas que las componen. Una transformación no suele atascarse porque falte una herramienta o una presentación impecable, sino porque la gente no entiende por qué debe cambiar, no ve qué gana con ello, no sabe exactamente cómo hacerlo, no tiene práctica suficiente o no recibe el refuerzo necesario para mantener el nuevo hábito cuando llega la presión del día a día. ADKAR ordena esas cinco condiciones:
- Conciencia (Awareness). Entender por qué se propone el cambio, qué problema resuelve y qué riesgo tiene seguir igual.
- Deseo (Desire). Querer participar o, al menos, encontrar razones suficientes y legítimas para comprometerse.
- Conocimiento (Knowledge). Saber qué hacer y cómo se realiza la nueva actividad.
- Habilidad (Ability). Ser capaz de aplicar ese conocimiento en situaciones reales, no solo en una sesión formativa.
- Refuerzo (Reinforcement). Disponer de condiciones, seguimiento y reconocimiento para sostener el nuevo comportamiento en el tiempo.
Su valor está en que obliga a mirar la adopción desde abajo y a identificar dónde se rompe la cadena. Supongamos que se implanta un CRM común. Un comercial puede entender la necesidad de compartir información, pero sospechar que la herramienta se usará para controlar su trabajo, y ahí falta deseo. Otro puede estar comprometido, pero desconocer el procedimiento, y le falta conocimiento. Un tercero ha aprobado el curso, pero no sabe gestionar las excepciones reales, y le falta habilidad. Un cuarto lo usa correctamente, hasta que su jefe vuelve a pedirle los informes en una hoja de cálculo, y le falta refuerzo. Cada bloqueo requiere una intervención distinta, y por eso un error habitual, saltar directamente a la formación, resuelve como mucho uno de los cuatro.
Cómo medir cada elemento de ADKAR con evidencias y no con encuestas de satisfacción
La aplicación habitual de ADKAR mide los cinco elementos con un cuestionario en el que cada persona puntúa del uno al cinco cuánto entiende, cuánto quiere, cuánto sabe, cuánto puede y cuánto se le refuerza. Es mejor que nada, pero mide lo que la gente cree o declara, no lo que hace. Una aplicación práctica busca para cada elemento una evidencia observable, y distingue con cuidado la evidencia que cuenta de la que parece contar y no cuenta.
| Elemento | Evidencia que cuenta | Evidencia que parece contar y no cuenta | Intervención si falla |
| Conciencia | La persona explica con sus palabras qué problema resuelve el cambio | Ha asistido a la presentación del programa | Explicar el porqué con datos de su propia área |
| Deseo | Los motivos de rechazo que expresa, clasificados con las cuatro lecturas de la resistencia | Una puntuación media de compromiso en una encuesta | Depende de la lectura: negociar, demostrar o corregir el diseño |
| Conocimiento | Resuelve correctamente ejercicios con casos reales, incluidas excepciones | Ha completado el curso y el examen tipo test | Formación con casos del propio trabajo |
| Habilidad | Desempeño real en el puesto: tiempos, errores y consultas a soporte | Ha superado la formación con buena nota | Acompañamiento en el puesto y usuarios expertos de referencia |
| Refuerzo | El comportamiento se mantiene a los tres y a los seis meses, sin sistemas paralelos | El uso del sistema es alto el primer mes | Cambiar indicadores, rutinas de los mandos y reconocimiento |
Diagnóstico ADKAR por colectivos: un mapa de calor aplicado a la empresa del ejemplo
Una aplicación práctica de ADKAR tiene que segmentar los colectivos según su papel, no enviar los mismos mensajes a toda la plantilla. Dirección, mandos, usuarios expertos, personal de atención, administradores de sistemas y áreas de control tienen motivos, riesgos y necesidades distintos, y la media de todos ellos no describe a ninguno. La herramienta más útil para hacerlo es un mapa de calor con una fila por colectivo y una columna por elemento, en el que cada casilla se marca como bien, en riesgo o bloqueada a partir de las evidencias de la tabla anterior. En la empresa del ejemplo, el mapa a los dos meses del arranque habría tenido este aspecto:
| Colectivo | Conciencia | Deseo | Conocimiento | Habilidad | Refuerzo |
| Agentes de atención | Bien | Bien | Riesgo | Bloqueo | Riesgo |
| Coordinadores veteranos | Bien | Bloqueo | Bien | Bien | Riesgo |
| Supervisores | Bien | Riesgo | Riesgo | Riesgo | Bloqueo |
| Técnicos de campo | Bloqueo | Riesgo | Riesgo | Riesgo | Riesgo |
El mapa convierte una impresión vaga, «la adopción va regular», en cuatro planes de acción distintos. Los agentes manejan bien los casos sencillos y no saben qué hacer con las excepciones, así que necesitan práctica guiada con excepciones reales y usuarios expertos a mano, no otro curso. Los supervisores siguen pidiendo los informes antiguos, y con ello mantienen vivo el modelo anterior: necesitan que la dirección retire esos informes y cambie lo que les pide, porque su bloqueo de refuerzo lo ha creado la propia dirección. Los técnicos de campo necesitan, sencillamente, que alguien les explique que el sistema ha cambiado la información que reciben. Y la casilla roja de los coordinadores veteranos, que entienden y dominan el sistema, es la más interesante del mapa, porque al investigarla resultó no ser un problema de adopción: era la objeción fundada de la que se hablaba en el apartado anterior.
Aquí aparece el límite conceptual decisivo de ADKAR. Si alguien entiende bien el cambio, sabe utilizarlo y lo rechaza porque ha detectado un fallo de seguridad, un riesgo de calidad o un deterioro del servicio, no se puede reducir automáticamente su objeción a un déficit de deseo. El modelo describe las condiciones para que una persona adopte un cambio, pero no tiene ninguna casilla para el caso en que la persona tiene razón y el cambio está mal diseñado. Por eso, antes de aplicar una intervención de deseo, hay que investigar el argumento.
Prosci es más que ADKAR: el Change Triangle y el proceso en tres fases
Sería injusto presentar Prosci como si solo propusiera cursos y comunicaciones, o como si identificara su metodología completa con ADKAR. Incorpora también el Prosci Change Triangle, que relaciona la definición de éxito con el patrocinio, la gestión del proyecto y la gestión del cambio; y su proceso en tres fases, organizado en preparar el enfoque, gestionar el cambio y sostener los resultados. Esa amplitud importa, porque significa que el propio Prosci reconoce que la adopción individual no basta y que tiene que conectarse con la dirección, con el proyecto y con los resultados.
A la vez, su foco diferencial sigue siendo facilitar la adopción y el lado humano de las iniciativas. No ofrece por sí solo las técnicas de rediseño de procesos, de arquitectura tecnológica, de economía del negocio ni de gobierno de sistemas autónomos que una transformación necesita. La discusión sobre si Prosci sirve como base de una transformación con IA se resuelve mejor separando ámbitos: es una herramienta válida para preparar y acompañar a las personas, y se vuelve insuficiente cuando se usa como sustituto del diagnóstico estratégico, del diseño del trabajo, del control de riesgos o de la evaluación de beneficios.
Dos advertencias completan el cuadro. La primera es que una certificación acredita formación en una metodología, no competencia universal para dirigir transformaciones complejas: la experiencia, el juicio profesional y la capacidad de combinar disciplinas siguen siendo indispensables, y no se gestiona igual una herramienta ofimática que una fusión, la sustitución de un ERP central o la automatización de decisiones que afectan a clientes. La segunda es que conviene leer con prudencia las cifras de éxito que circulan sobre estas metodologías, porque buena parte proceden de estudios que las propias firmas realizan sobre sus propios métodos, con clasificaciones hechas después de conocer el resultado. Eso no las invalida, pero no son evidencia independiente.
Modelo de Lewin y mapa de marcos de cambio: qué modelo usar para cada decisión
Kurt Lewin popularizó a mediados del siglo pasado una lectura del cambio en tres momentos que sigue siendo la más intuitiva de todas. Descongelar consiste en cuestionar la lógica vigente, hacer visible por qué el modelo actual ya no basta y preparar a las personas para abandonar determinadas prácticas. Cambiar es experimentar, aprender, rediseñar tareas y acompañar la operación mientras el nuevo modelo adquiere forma. Y recongelar es estabilizar los comportamientos útiles mediante procedimientos, roles, indicadores, sistemas e incentivos, para que la organización no vuelva a sus hábitos anteriores.
La metáfora ayuda a entender por qué tantas iniciativas se desvanecen cuando, tras el despliegue, todos vuelven a trabajar como antes: faltó la tercera fase. Pero en entornos de cambio continuo, y particularmente con inteligencia artificial, no siempre existe un estado final estable al que congelar, porque los modelos, las herramientas y los procesos que los rodean siguen evolucionando cada pocos meses. En esos entornos, consolidar debe entenderse como institucionalizar principios, controles y capacidades de aprendizaje, dejando abierta la evolución del diseño. No queremos congelar errores: queremos evitar que desaparezcan las mejoras que ya han demostrado su valor.
Mapa práctico de los marcos de transformación y gestión del cambio
Con los marcos de diseño y los de cambio ya descritos, se puede construir el mapa que responde a la pregunta práctica: qué modelo usar para cada decisión. No se trata de implantar todos los modelos, sino de usar la perspectiva adecuada para cada decisión y mantener un lenguaje común sobre el resultado esperado. La tercera columna de la tabla es tan importante como la segunda, porque recoge el límite de cada marco, que es donde suelen empezar los problemas.
| Necesidad | Enfoque más útil | Advertencia |
| Entender el problema y sus causas | Diagnóstico causal, procesos y análisis de datos | Una correlación no demuestra la causa |
| Diseñar estructura, roles, decisiones e incentivos | Star Model de Galbraith | El organigrama es solo una de las cinco piezas |
| Detectar dependencias y conocimiento informal | Nadler-Tushman y sistemas sociotécnicos | No confundir un control invisible con desperdicio |
| Comprobar la coherencia organizativa | McKinsey 7S | La lista de dimensiones no diseña las soluciones |
| Movilizar liderazgo, coaliciones y equipos | Kotter | La movilización no valida la estrategia |
| Diagnosticar barreras personales de adopción | ADKAR | Una objeción puede ser un dato valioso, no resistencia irracional |
| Gestionar la transición y estabilizar nuevas prácticas | Lewin | No convertir el estado futuro en un dogma inamovible |
| Revisar supuestos y rectificar decisiones | Aprendizaje de doble bucle de Argyris | No limitar el aprendizaje a ejecutar mejor el plan inicial |
El mapa resume la idea central de esta parte del artículo. Los modelos clásicos de gestión del cambio son útiles en su ámbito e insuficientes fuera de él: Kotter, ADKAR y Lewin ofrecen un vocabulario y una secuencia prácticos para movilizar, cómo conseguir la adopción y cómo estabilizar, y no dicen casi nada sobre si lo que se moviliza, se adopta y se estabiliza era lo que había que hacer. Para eso están las otras cinco filas, que es donde la mayoría de las transformaciones invierte menos.
Gobierno del programa de transformación: autoridad, método de ejecución y entregables técnicos
Definir una estrategia y convencer a la plantilla no construye por arte de magia las integraciones, los datos maestros, los controles ni los procesos. Hace falta disciplina de ejecución, y esa disciplina empieza por los papeles. Todo programa de transformación necesita, como mínimo, un patrocinador ejecutivo, un responsable de la transformación, propietarios de los procesos afectados, responsables técnicos, responsables del cambio, equipos operativos y una función de control independiente proporcionada al riesgo. Cuando uno de esos papeles no tiene nombre, sus decisiones las acaba tomando otro, normalmente el que menos sabe de ellas.
Tres preguntas que revelan si el gobierno de la transformación tiene autoridad efectiva
Los consultores más experimentados no empiezan preguntando por módulos, licencias o integraciones, sino por tres cuestiones mucho más incómodas, porque saben que ahí se decide el destino real del proyecto. La primera es quién tiene autoridad real para resolver un conflicto entre áreas. Sin un dueño claro, los desacuerdos terminan en retrasos, en concesiones contradictorias y en comités que se reúnen sin decidir. La segunda es quién será responsable del resultado cuando desaparezca el equipo de proyecto. Sin un propietario del beneficio, el éxito se reduce a entregar funcionalidades. Y la tercera es quién puede detener o rediseñar la iniciativa si aparecen evidencias negativas. Sin una vía de rectificación, los incentivos de calendario y de reputación pueden mantener vivo durante años un proyecto equivocado.
Estas tres preguntas ayudan a separar los programas serios de los que no lo son, porque no evalúan si la empresa quiere modernizarse de palabra, sino si está preparada para asumir el coste real del cambio: concentrar poder de decisión, renunciar a hábitos cómodos y aceptar que una decisión tomada puede revisarse. La gobernanza debe fijar las decisiones reservadas, los criterios de escalado, los umbrales de riesgo, el presupuesto, las responsabilidades sobre datos y plataformas y los mecanismos de resolución de dependencias, y debe funcionar a diario. Un comité mensual no compensa la ausencia de decisiones operativas diarias; como mucho, se entera con un mes de retraso de las que nadie tomó.
Metodología predictiva, ágil o híbrida: cómo elegir según la incertidumbre y el riesgo
No existe una metodología de proyectos que sirva por igual a todos los contextos, y la discusión sobre si una empresa «es ágil» suele ocultar la pregunta que importa. Un enfoque predictivo es apropiado cuando los requisitos, las dependencias y los controles son relativamente estables, como en determinadas migraciones reguladas o actuaciones de infraestructura. Un enfoque ágil o iterativo es útil cuando las necesidades y las soluciones tienen que descubrirse mediante entregas frecuentes, observación y aprendizaje. Y un enfoque híbrido, el más habitual en las grandes transformaciones, combina la planificación de la arquitectura, los contratos, el cumplimiento o las migraciones con ciclos iterativos para los procesos y los productos.
Las prácticas concretas son instrumentos al servicio de esa elección. Scrum, Kanban, las prácticas de ingeniería y los marcos de escalado pueden organizar el trabajo; Lean ayuda a eliminar desperdicio; Six Sigma aporta el análisis de la variabilidad; ITIL ofrece prácticas relevantes cuando cambia la operación de servicios; y el gobierno de cartera permite coordinar las dependencias entre iniciativas. Ninguno de ellos determina por sí solo que la inversión tenga sentido, y la elección depende de la incertidumbre, la criticidad, las interdependencias, la tolerancia al error y la capacidad de entrega. La pregunta no es si la empresa es ágil, sino si aprende y entrega con la disciplina adecuada a lo que está haciendo. Quien quiera bajar al detalle de cómo se organiza ese trabajo en el día a día encontrará un desarrollo completo en el artículo sobre cómo organizar el trabajo con Jira, Confluence y GitHub.
Los entregables técnicos que no deben desaparecer del plan del proyecto
Además de las aplicaciones y las funcionalidades, que son lo que todo el mundo ve, un programa de transformación necesita siete entregables que se recortan con facilidad cuando el calendario aprieta. La arquitectura y las integraciones, con la definición de interfaces, disponibilidad y responsabilidades. La estrategia de datos: calidad, migración, reconciliación, permisos, trazabilidad y propiedad. La seguridad, la privacidad, la continuidad, la observabilidad y la gestión de incidentes y cambios. Las pruebas funcionales, de punta a punta, de rendimiento, de excepción y de recuperación. Los procesos operativos y el modelo de soporte para después del arranque. La formación aplicada, la base de conocimiento y la transferencia desde proveedores o expertos. Y el plan de despliegue, con marcha atrás, estabilización y criterios formales de aceptación.
De los siete, las pruebas de excepción y el plan de marcha atrás suelen estar entre los que más dinero ahorran y entre los primeros en desaparecer. Que un sistema funcione en una demostración no prueba que la empresa pueda operar con él, porque una demostración recorre los casos que alguien eligió para que funcionaran. La operación real recorre todos los demás.
Transformaciones con ERP y grandes plataformas: clean core, excepciones justificadas y sistemas paralelos
Las implantaciones de ERP ilustran con especial claridad la tensión entre tecnología, procesos, poder y cultura. Una dirección puede pensar que un software comercial reconocido reorganizará espontáneamente la empresa y corregirá años de malas prácticas. En realidad, el ERP no reorganiza nada por sí solo: obliga a explicitar decisiones que antes permanecían ambiguas, como qué dato manda, qué departamento decide, qué excepciones se permiten y cómo se ejecuta el proceso de punta a punta. Un ERP no rescata a una organización ambigua; la obliga a definirse. El análisis de siete grandes fracasos en la implantación de ERP, de Lidl a Revlon, muestra lo que ocurre cuando esas decisiones se aplazan hasta que el sistema ya está en producción.
Rediseñar los procesos antes de automatizar el desorden
Un proceso confuso no se vuelve bueno por pasar a un sistema más rápido. Si contiene autorizaciones redundantes, contradicciones entre áreas o datos inconsistentes, la automatización amplía y propaga sus defectos, porque un software actúa como un amplificador de lo que encuentra. El diseño del modelo futuro tiene que liderarlo un equipo con autoridad y conocimiento transversal, con una participación estructurada de quienes realizan el trabajo. Y rediseñar no siempre significa añadir: a veces la transformación consiste en quitar complejidad antes de automatizar nada. Es lo que muestra el giro de Starbucks con Brian Niccol, que empezó por recortar la carta y por devolver la tecnología a la trastienda para que dejara de complicar el trabajo en el mostrador.
Aquí conviene matizar una práctica muy extendida, la de diseñar el modelo futuro a puerta cerrada para evitar que cada área defienda su feudo. La intención es comprensible y el riesgo que quiere evitar es real, pero el remedio produce otro problema: las excepciones y los riesgos reales viven precisamente en la operación, y un diseño hecho sin ella los descubre después del arranque. Tampoco es viable someter cada regla a un consenso ilimitado. La combinación correcta es una participación profunda para descubrir y contrastar, y una decisión clara para cerrar los conflictos, tomada por quien tiene la autoridad para tomarla.
El principio de clean core aplicado con criterio: cinco preguntas antes de personalizar
El valle de la transición, del que se habla en el apartado siguiente, se vuelve especialmente peligroso cuando la organización intenta adaptar el sistema a sus viejas formas de trabajar en lugar de adaptarse ella al nuevo modelo. Empiezan las presiones internas: peticiones constantes de cambios, excepciones y pequeños ajustes que, acumulados, distorsionan la lógica del sistema. Para evitarlo, ecosistemas como SAP han popularizado el principio de clean core: conservar el núcleo estándar lo más limpio posible y evitar las personalizaciones que complican las actualizaciones, el soporte y la integración. Es un principio valioso, porque cada modificación del núcleo puede convertirse en deuda futura que se paga en cada actualización.
Sin embargo, estandarizar no significa aceptar sin análisis cualquier proceso incluido en el producto. Una excepción puede responder a una obligación regulatoria, a una ventaja competitiva o a una necesidad legítima de un cliente importante. Antes de personalizar, conviene hacerse cinco preguntas: si la diferencia respecto al estándar crea valor demostrable o solo reproduce una costumbre; si puede resolverse cambiando el proceso, mediante configuración o con una extensión desacoplada del núcleo; qué coste total supondrá mantener la excepción durante años; qué control, dato o capacidad se perdería al imponer el estándar; y quién aprueba la decisión y asume su coste y su riesgo.
Las cinco preguntas ordenan las opciones de la más barata de mantener a la más cara: adoptar el estándar, cambiar el proceso para que encaje, configurar lo que el producto ya permite, construir una extensión fuera del núcleo y, solo como último recurso, modificar el núcleo. La disciplina correcta consiste en estándar por defecto, excepción justificada y diseño mantenible, no en obediencia ciega al proveedor ni en reproducir con software nuevo la forma de trabajar de siempre. Las organizaciones que lo consiguen limitan las excepciones, priorizan las buenas prácticas estándar y solo permiten adaptaciones cuando aportan un valor que alguien ha firmado.
Sistemas paralelos: cuándo son una transición legítima y cuándo una doble operativa perpetua
Durante una migración puede ser necesario operar temporalmente dos sistemas o realizar reconciliaciones manuales, y eso es una transición legítima. El riesgo aparece cuando la organización mantiene para siempre la vieja hoja de cálculo o el sistema local porque no confía en el nuevo, mientras sigue pagando y alimentando ambos. Mientras exista una doble operativa, el sistema nuevo nunca se convertirá en la fuente única de verdad, y la implantación quedará saboteada desde dentro sin que nadie haya decidido sabotearla.
Por eso tiene que existir una decisión explícita sobre las fuentes de verdad, los responsables de cada dato, la reconciliación, la transición y la retirada. Pero aquí también hay un error simétrico. Retirar un sistema paralelo antes de comprobar qué controles y funciones ocultas contenía puede resultar tan peligroso como mantenerlo indefinidamente, porque a menudo la hoja paralela existe precisamente porque hace algo que el sistema oficial no hace. La retirada debe basarse en pruebas, y su mejor preparación es el inventario de controles informales del diagnóstico: cada hoja paralela es una fila de ese inventario.
Curva de adopción y valle de productividad: cómo distinguir una transición difícil de un diseño equivocado
Muchas transformaciones atraviesan una fase incómoda: el modelo anterior ya se ha alterado, el nuevo todavía no funciona con soltura y la productividad cae temporalmente. Aparecen dudas, errores, carga de trabajo duplicada, nostalgia del sistema anterior y presión por volver atrás. Ese valle, que en la literatura sobre implantaciones se llama a veces valle de la desesperación, no es necesariamente una anomalía: es una consecuencia normal de que la organización tenga que reaprender a funcionar.
No conviene, sin embargo, convertir ese descenso en una ley universal. Algunos cambios mejoran desde el principio y otros fracasan sin recuperarse nunca. El peligro de dar el valle por supuesto es que cualquier caída de rendimiento se interpreta como parte natural de la transición, y eso impide ver a tiempo las que no lo son. Anticipar una transición difícil ayuda a preparar capacidad de soporte, plazos y expectativas realistas, pero solo si a la vez se vigilan las señales que distinguen un valle de un diseño roto.
Señales para distinguir el valle de la transición de un diseño que no funciona
Las dos curvas empiezan igual, con una caída de rendimiento tras el arranque, y por eso se confunden. Lo que las distingue es la dirección de unas pocas señales en las primeras semanas. En una transición difícil, los errores bajan semana a semana, las consultas a soporte disminuyen y los usuarios más expertos son los primeros en recuperar y superar su rendimiento anterior. En un diseño equivocado ocurre lo contrario: los mismos errores se repiten con la misma frecuencia, crecen los atajos y las hojas paralelas, y los expertos rinden peor que antes, porque el sistema les impide aplicar precisamente el criterio que los hacía expertos.
La empresa del ejemplo mostraba las tres señales del segundo tipo, y la última era la más elocuente. Ninguna de ellas, por separado, demuestra que el diseño esté mal, pero las tres juntas y sostenidas durante semanas obligan a revisarlo. Las coordinadoras veteranas, que antes resolvían los casos complejos más deprisa que nadie, eran ahora las más lentas, porque el nuevo circuito las obligaba a reabrir y reasignar manualmente lo que la plataforma había clasificado mal. Cuando los mejores rinden peor de forma sostenida, es improbable que el problema se resuelva con más formación o con más paciencia, y lo prudente es volver al diseño. Es la flecha larga de la metodología, y de ella se ocupa el apartado sobre el aprendizaje de doble bucle.
Cinco medidas para atravesar la transición sin perder la operación
Cuando las señales indican que se trata de una transición difícil y no de un diseño roto, hay cinco medidas especialmente útiles. La primera es proteger la operación, reservando capacidad para resolver incidencias y casos complejos mientras los equipos aprenden, en lugar de reducir plantilla el mismo día del arranque. La segunda es seleccionar pilotos representativos, que prueben tanto escenarios sencillos como excepciones, picos de carga y dependencias entre áreas; un piloto que solo recorre casos fáciles produce una confianza que la operación desmentirá. La tercera es acompañar en el puesto de trabajo, con usuarios expertos, supervisores y equipos de soporte que tengan capacidad real de decidir y corregir sobre la marcha.
La cuarta medida es conseguir victorias tempranas verificables, en el sentido estricto que se describió al hablar de Kotter: un retrabajo concreto que desaparece, una gestión que se acelera sin generar defectos, una doble introducción de datos que se elimina. Y la quinta es publicar los problemas y sus soluciones. La transparencia sobre los errores y sobre cómo se corrigen es mucho más creíble que una comunicación que solo celebra triunfos, porque la plantilla ya conoce los errores y lo único que no sabe es si la dirección también. Si un piloto no mejora el negocio, descubrirlo antes de escalarlo es también una victoria de gestión, y probablemente la más rentable de todas.
Transformación con inteligencia artificial: qué cambia cuando la tecnología recomienda, decide y actúa
Históricamente, el temor que despertaba un cambio tecnológico en una plantilla era tener que aprender una pantalla nueva y una secuencia distinta de pasos. En un ERP tradicional, muchas personas necesitan aprender eso, y la gestión del cambio se diseñó en buena medida para ayudarlas a hacerlo. La inteligencia artificial añade una cuestión de mayor alcance: no solo cambia cómo se realiza una actividad, sino que puede cambiar quién la realiza, qué juicio se utiliza, quién decide y quién responde del resultado. Por eso todo lo dicho hasta aquí se vuelve más exigente con ella, no menos.
Una IA puede recomendar, redactar, clasificar, detectar anomalías o ejecutar acciones sobre otros sistemas. Un agente con permisos de escritura puede abrir expedientes, modificar registros, interactuar con clientes o iniciar procesos sin que nadie lo revise antes. La diferencia entre asistir y actuar no es cosmética: cambia el perfil de riesgo, la necesidad de supervisión y la respuesta a la pregunta de quién responde cuando algo sale mal. Una transformación con IA que no distingue entre las dos cosas está gobernando con las mismas reglas un corrector ortográfico y un sistema que concede compensaciones a los clientes.
Cómo analizar el trabajo por capacidades y decisiones, no solo por puestos
El análisis habitual del impacto de la IA se hace por puestos: qué porcentaje de un puesto es automatizable. Es una unidad equivocada, porque un puesto es un conjunto de tareas y decisiones de naturaleza muy distinta, y la pregunta útil es cómo se reparte cada una. Un punto de partida sencillo es distinguir cuatro formas de distribuir el trabajo entre personas y tecnología, cada una con su propia pregunta de gobierno.
| Distribución del trabajo | Ejemplo | Pregunta de gobierno |
| Trabajo esencialmente humano | Decisiones éticas complejas, relaciones de confianza, negociación sensible | ¿Qué criterio, autoridad y capacidad deben preservarse? |
| Trabajo humano asistido por IA | La IA resume el historial y propone una respuesta; la persona decide y responde | ¿Cómo evitamos que la persona acepte la propuesta sin revisarla? |
| IA supervisada por personas | La IA clasifica y resuelve los casos estándar; las personas atienden las excepciones que el sistema deriva | ¿Quién detecta los errores que el sistema no sabe que comete? |
| Automatización con control por muestreo | Volumen alto, riesgo bajo y reversible, revisión periódica de una muestra | ¿Qué tasa de error es tolerable y cómo se mide de forma continua? |
La tabla permite repartir las tareas de un mismo puesto en varias filas a la vez, que es lo que de verdad ocurre. En la empresa del ejemplo, un agente de atención hace trabajo de las cuatro: negocia con un cliente enfadado, revisa la propuesta de resolución que le prepara la plataforma, atiende las excepciones que el sistema le deriva y confía en que la clasificación automática de las solicitudes rutinarias sea correcta. El error del diseño original fue tratar como automatización con control por muestreo, la cuarta fila, algo que pertenecía a la tercera: las averías repetidas parecían rutinarias y no lo eran.
Niveles de autonomía de la IA: cómo decidir cuánta conceder a cada acción
Para la tercera y la cuarta fila hace falta una segunda herramienta: una escala de autonomía que se aplica a cada acción concreta, no al sistema en su conjunto. La que se utiliza en este blog tiene seis niveles: el sistema informa (0), recomienda (1), prepara la acción para que una persona la confirme (2), ejecuta y deja traza (3), ejecuta salvo excepción (4) u opera de forma autónoma (5). Un mismo agente puede tener nivel 4 para clasificar una solicitud, nivel 2 para proponer una compensación y nivel 0 para cualquier cosa que afecte a un contrato. El desarrollo completo de esta escala, con los criterios para asignarla, está en el artículo sobre cómo organizar una transformación con agentes de IA, y la decisión técnica que va asociada, cuánta autonomía necesita de verdad cada problema, desde un modelo que responde hasta un sistema multiagente, en el de arquitectura agéntica.
El criterio para decidir el nivel de cada acción no es la confianza en el modelo, sino el riesgo de la acción, que depende de cuatro factores: la probabilidad de que el sistema se equivoque, la autonomía con la que actúa, el alcance de lo que puede afectar y lo difícil que es deshacer el error. Una acción frecuente, de alcance limitado y fácilmente reversible admite mucha autonomía aunque el sistema se equivoque a veces; una acción poco frecuente, de gran alcance e irreversible necesita una persona delante aunque el sistema casi nunca falle. La autonomía, además, no se concede de una vez: se sube un nivel cuando la evidencia de la operación lo justifica, y se baja en cuanto deja de hacerlo.
Supervisión humana y sesgo de automatización: cómo preservar el criterio de los expertos
Casi todos los diseños de IA incluyen una persona que revisa, y casi todos dan por supuesto que esa persona revisará con el mismo criterio que tenía antes de que existiera el sistema. La evidencia disponible indica lo contrario: cuando una persona trabaja junto a un sistema que casi siempre acierta, tiende a aceptar sus propuestas también cuando se equivoca, y la experiencia protege menos de lo que se cree. En un estudio publicado en Radiology en 2023, los radiólogos con más de quince años de experiencia leyendo mamografías acertaron el 82,3 % de las veces cuando una IA simulada les sugería la categoría correcta, y solo el 45,5 % cuando les sugería una incorrecta; en los más noveles, la diferencia fue del 79,7 % al 19,8 %. Conviene leer bien la cifra: no mide una caída del rendimiento de esos profesionales a lo largo del tiempo tras adoptar una IA real, sino la diferencia entre casos con sugerencias correctas e incorrectas de un sistema que se equivocaba a propósito. Lo que muestra es el mecanismo: la sugerencia arrastra el juicio, también el de los expertos.
El segundo efecto es más lento y más difícil de ver: la pérdida de la habilidad que deja de practicarse. Un estudio observacional publicado en The Lancet Gastroenterology & Hepatology en 2025, sin asignación aleatoria y con las limitaciones que eso supone, encontró que la tasa de detección de lesiones de un grupo de endoscopistas, en las exploraciones que hacían sin ayuda, bajó del 28,4 % al 22,4 % después de varios meses trabajando habitualmente con IA. Y un experimento de Anthropic con 52 programadores que aprendían una biblioteca nueva encontró que el grupo que trabajó con IA obtuvo en la prueba posterior una nota un 17 % inferior a la del grupo que trabajó sin ella, sin una ganancia de tiempo estadísticamente significativa. Lo que distinguía a quienes sí aprendían usando la IA era que le preguntaban por qué, en lugar de pedirle directamente el resultado.
De esa evidencia se siguen cuatro decisiones de diseño que cualquier transformación con IA debería tomar explícitamente. Mantener una proporción del trabajo que los expertos siguen haciendo sin ayuda, para que conserven el criterio que necesitan para supervisar. Presentar la propuesta del sistema después de que la persona haya formado su propia opinión en los casos de mayor riesgo, y no antes. Medir de forma periódica la calidad de la revisión humana, con casos de control cuya respuesta correcta se conoce. Y sustituir de forma deliberada la función formativa de las tareas que se automatizan, porque son las que hoy convierten a un empleado nuevo en el experto de dentro de cinco años.
IA y empleo: cómo comunicar con honestidad el impacto sobre tareas y puestos
Presentar la IA como una herramienta que amplifica las capacidades de los empleados es un enfoque positivo y, en muchos casos, correcto. Pero no debe convertirse en un mensaje artificialmente tranquilizador. Hay transformaciones que efectivamente permitirán prescindir de determinadas actividades y, en algunos casos, de determinados puestos, y el liderazgo tiene que reconocer esa posibilidad y gestionar sus consecuencias con transparencia. La confianza se destruye cuando se promete que nadie será sustituido y, al cabo de unos meses, ocurre exactamente eso.
Lo que se sabe hasta ahora del efecto de la IA sobre el empleo ayuda a calibrar ese mensaje. Un estudio de Anders Humlum y Emilie Vestergaard sobre unos 25.000 trabajadores y 7.000 centros de trabajo daneses encontró un ahorro de tiempo de alrededor del 3 % de la jornada, y efectos prácticamente nulos sobre salarios y horas trabajadas; la mayoría de quienes ahorraban tiempo lo dedicaban a otras tareas. Los datos de nóminas de ADP analizados por investigadores de Stanford muestran, en cambio, una caída del empleo de los trabajadores de 22 a 25 años en las ocupaciones más expuestas, que opera sobre todo por no contratar y que los propios autores presentan como un patrón descriptivo, no como un efecto causal demostrado. El impacto que empieza a verse no es tanto el despido masivo como la desaparición silenciosa de los puestos de entrada, que es justo donde se forman los expertos del futuro.
El caso que mejor ilustra el riesgo de equivocarse en las dos direcciones a la vez es el del Commonwealth Bank of Australia en 2025. El banco anunció la eliminación de 45 puestos de atención telefónica tras implantar un asistente de voz, y semanas después dio marcha atrás reconociendo en un comunicado que no había considerado adecuadamente todas las circunstancias relevantes del negocio, y que ese error significaba que los puestos no eran redundantes. Había medido la actividad que el sistema absorbía y no el trabajo que dejaba sin hacer, que es la misma confusión entre adopción y valor con la que empieza este artículo.
Un mensaje honesto sobre la IA y el empleo tiene cuatro componentes, y ninguno es una promesa que no se pueda cumplir. Qué tareas va a dejar de hacer cada colectivo y qué tareas nuevas va a asumir. Qué decisiones sobre la plantilla están ya tomadas, cuáles dependen de los resultados y cuándo se tomarán. Qué compromisos concretos asume la empresa, por ejemplo de recolocación, formación o no contratar externamente para los puestos nuevos. Y qué no se sabe todavía, dicho con esas palabras, porque la incertidumbre reconocida genera mucha menos desconfianza que la certeza que después se desmiente.
Gobierno de la IA y Reglamento europeo de IA: qué obligaciones conviene preparar ya
El gobierno de la IA forma parte del diseño de la transformación, no de un trámite posterior de cumplimiento. Como mínimo, cada sistema necesita un inventario que diga qué hace, con qué datos y con qué nivel de autonomía; un responsable de negocio con nombre; criterios de calidad medidos antes y después del despliegue; trazabilidad de las decisiones; un procedimiento para detenerlo; y una revisión periódica de su rendimiento y de sus efectos. Son exactamente los mismos elementos que la matriz de derechos de decisión y la escala de autonomía ya exigen, lo que indica que un buen diseño organizativo adelanta buena parte del trabajo de cumplimiento.
En la Unión Europea, el marco es el Reglamento de Inteligencia Artificial, cuyo calendario modificó el Reglamento (UE) 2026/1744, en vigor desde el 27 de julio de 2026. Las obligaciones para los sistemas de alto riesgo del anexo III, entre los que están los que se usan para decisiones de empleo, selección o evaluación de trabajadores, se aplican desde el 2 de diciembre de 2027, y las del anexo I, desde el 2 de agosto de 2028. Las obligaciones de transparencia del artículo 50, en cambio, no se aplazaron y rigen desde el 2 de agosto de 2026: entre ellas, que las personas sepan que están interactuando con un sistema de IA cuando no sea evidente, algo que afecta directamente a cualquier plataforma de atención al cliente como la de la empresa del ejemplo.
Medición del valor de la transformación: indicadores de adopción, de resultado y de capacidades
Todo lo anterior desemboca en la quinta pregunta de la introducción: cómo sabremos que fue una buena decisión. Es la pregunta que más a menudo se queda sin responder, no por falta de datos, sino porque nadie diseñó al principio la forma de responderla. Una transformación que no definió antes de empezar qué iba a medir, con qué línea base y contra qué comparación, no puede demostrar después que ha creado valor, por mucho que lo haya creado. Y, lo que es peor, tampoco puede descubrir que lo está destruyendo.
Las tres capas de indicadores y los contraindicadores
Los indicadores de una transformación se organizan en tres capas, y cada una responde a una pregunta distinta. La capa de adopción mide si el cambio se usa: porcentaje de uso, formación completada, satisfacción con la herramienta. La capa de resultado mide si el negocio ha mejorado: plazo, calidad, retrabajo, coste, experiencia del cliente, ingresos. Y la capa de capacidades mide si la organización es más competente que antes: si conserva el criterio experto, si es más resiliente ante los fallos y si aprende más deprisa. Las tres son necesarias, pero explican cosas muy distintas, y la regla que ordena su uso es sencilla: ninguna decisión de consolidar un cambio se toma con indicadores de la capa de adopción.
A las tres capas hay que añadir una categoría que casi ningún cuadro de mando incluye, la de los contraindicadores. Un contraindicador mide lo que puede empeorar mientras el objetivo principal mejora: si el objetivo es reducir el tiempo de atención, el contraindicador son las reaperturas; si el objetivo es reducir el coste por gestión, el contraindicador son las quejas. Los contraindicadores se definen antes de empezar y se miden desde el primer día, porque son la única defensa contra la ley de Goodhart, según la cual un indicador deja de ser útil en cuanto se convierte en objetivo. En la empresa del ejemplo, el porcentaje de gestiones que pasaban por la plataforma se convirtió en el objetivo de todos, y por eso dejó de decir nada sobre el negocio.
Cuadro de mando de la transformación: el ejemplo de la empresa de servicios a los seis meses
La tabla siguiente reconstruye el cuadro de mando que la empresa del ejemplo debería haber tenido, con su línea base y la situación a los seis meses del arranque. Las cifras son ilustrativas. Leída por capas, la tabla explica en un minuto lo que la dirección tardó medio año en entender: la capa de adopción está en verde, la de resultado es mixta y la de capacidades da una alarma y deja un hueco que nadie mide.
| Capa | Indicador | Línea base | A los seis meses | Lectura |
| Adopción | Gestiones que pasan por la plataforma | 0 % | 96 % | Objetivo cumplido; no dice nada sobre el negocio |
| Resultado | Plazo medio, casos sencillos | 2,1 días | 1,2 días | Mejora real, concentrada en lo que ya funcionaba |
| Resultado | Plazo medio, casos complejos | 9,5 días | 12,0 días | Empeora, y es donde están los clientes que se van |
| Resultado | Coste por gestión | Índice 100 | Índice 86 | Mejora, pero no descuenta el retrabajo |
| Contraindicador | Reaperturas a 30 días | 8 % | 13 % | Alerta: parte del ahorro se devuelve como retrabajo |
| Contraindicador | Reparaciones facturadas en garantía | Casi nulas | Más de cien al mes | Alerta: ha desaparecido un control informal |
| Capacidades | Casos complejos resueltos con intervención de un coordinador veterano | 70 % | 25 % | Por sí solo no prueba nada: puede ser eficiencia o pérdida de criterio |
| Capacidades | Acierto de los coordinadores en casos de control resueltos sin ayuda | 91 % | 78 % | Alerta: esta sí mide directamente el criterio experto |
| Capacidades | Semanas hasta que un agente nuevo resuelve excepciones sin ayuda | 12 | Sin medir | Nadie sabe si los nuevos están aprendiendo el oficio |
La primera fila de capacidades es una trampa fácil. Que los expertos intervengan menos en los casos complejos puede significar que se está perdiendo su criterio, pero también que el sistema resuelve bien más casos y ya no hace falta llamarlos, que es justo lo que se buscaba. Para saber cuál de las dos cosas ocurre hay que medir la capacidad directamente: casos de control con respuesta conocida que los expertos resuelven sin ayuda, calidad de las decisiones revisadas por muestreo y proporción de excepciones que los equipos cierran por sí mismos sin reaperturas. La fila siguiente hace eso, y es la que justifica la alarma.
La última fila es tan reveladora como las alarmas. Una capacidad que nadie mide es una capacidad que nadie protege, y en una transformación con IA las capacidades que corren más riesgo suelen ser las que menos se miden, porque antes nunca había hecho falta: se formaban solas, haciendo el trabajo que ahora hace el sistema.
Capacidad liberada, ahorro materializado y beneficio neto: cómo traducir una mejora en valor económico
La fila del coste por gestión esconde una distinción que conviene hacer explícita ante cualquier comité de inversión: liberar tiempo de trabajo no equivale a ahorrar dinero. Si una automatización ahorra veinte minutos diarios a cuarenta empleados, libera unas trece horas de trabajo al día, cerca de 2.900 horas en un año de unas 220 jornadas, el equivalente aproximado a 1,7 personas a tiempo completo. Pero ese tiempo no aparece por sí solo en la cuenta de resultados. El ahorro solo se materializa cuando la capacidad liberada se convierte en menos gasto, en contratación evitada, en más producción o en más ventas, y si nadie decide a qué se destina, se diluye en el día a día. Es lo que encontraron Humlum y Vestergaard en Dinamarca: la mayoría de quienes ahorraban tiempo con la IA lo dedicaban a otras tareas, sin efecto apreciable en horas ni en salarios.
| Concepto | Qué mide | Ejemplo con los cuarenta empleados | Cuándo puede presentarse como resultado |
| Capacidad liberada | El tiempo de trabajo que deja de dedicarse a una tarea | Unas 2.900 horas al año, cerca de 1,7 personas a tiempo completo | Nunca por sí sola: es un potencial, no un resultado |
| Ahorro materializado | La parte de esa capacidad convertida en menos gasto, contratación evitada o más actividad facturable | No se cubren dos vacantes previstas y desaparecen las horas extra de los picos | Cuando el gasto o los ingresos se comparan con la línea base |
| Beneficio económico neto | El ahorro materializado menos los costes de operar y de la transición | Ahorro anual menos licencias, soporte, supervisión humana, retrabajo y productividad perdida durante el aprendizaje | Es la cifra que justifica la inversión |
| Capacidades adquiridas o deterioradas | Lo que la organización sabe hacer mejor o peor, aunque todavía no tenga traducción monetaria | Criterio experto, tiempo de aprendizaje de los nuevos, resiliencia ante fallos | Se informa junto al beneficio neto, y no se omite por no tener precio |
La consecuencia práctica es que el destino de la capacidad liberada tiene que decidirse en el caso de transformación, antes de aprobar la inversión, y tener un responsable con nombre. Un caso de negocio que multiplica los minutos ahorrados por el coste de una hora y presenta el resultado como ahorro está sumando capacidad, no dinero, y así es como muchos proyectos resultan rentables sobre el papel sin llegar nunca a la cuenta de resultados. La cuarta fila protege del error contrario: una transformación puede arrojar un beneficio neto positivo mientras deteriora capacidades que la empresa necesitará después, y las dos cosas tienen que estar en el mismo informe.
Línea base, denominador y grupo de comparación: cómo atribuir el resultado al cambio
Medir bien exige tres cosas que se deciden antes de empezar. La primera es una línea base medida con el mismo método que se usará después, por tipo de caso y durante el tiempo suficiente para que recoja la estacionalidad. La segunda es un denominador explícito, porque es donde se esconden casi todos los trucos de las cifras sobre transformación. Un ejemplo reciente lo muestra mejor que cualquier explicación: según un análisis de la Reserva Federal publicado en abril de 2026, a finales de 2025 el 18 % de las empresas estadounidenses usaba IA, pero el 41 % de los trabajadores la usaba, y el 78 % de los trabajadores estaba empleado en una empresa que la había adoptado. Tres cifras correctas sobre el mismo fenómeno, que solo se diferencian en lo que cuentan.
La tercera es un grupo de comparación, porque sin él es imposible saber qué parte de la mejora se debe al cambio y qué parte habría ocurrido de todos modos. No hace falta un experimento perfecto: puede bastar con desplegar por oleadas y comparar, durante unas semanas, las unidades que ya tienen el cambio con las que todavía no, o con reservar una pequeña parte del volumen al proceso anterior. Pero la comparación por oleadas tiene una trampa. Las unidades que se despliegan primero rara vez se eligen al azar: suelen ser las más maduras, las que tienen mejores responsables o las que reciben más soporte, y cualquiera de esas diferencias puede explicar el resultado tanto como el cambio. Para que la comparación sirva, los grupos tienen que ser comparables, y hay que controlar las diferencias de volumen, de complejidad de los casos y de estacionalidad.
Tres prácticas ayudan a conseguirlo. Decidir el orden de las oleadas con criterios explícitos, o por sorteo cuando sea posible, y no por el entusiasmo de cada responsable. Comparar la evolución de cada grupo respecto a su propia línea base, y no solo el nivel final de uno frente al otro. Y analizar los resultados por tipo de caso, para que una unidad que recibe casos más sencillos no parezca mejor de lo que es. El banco singapurense DBS publica desde hace años en su informe anual el valor económico de sus iniciativas de IA medido contra grupos de control y pruebas A/B, y es uno de los pocos ejemplos públicos de cómo puede medir una gran empresa lo que gana con una transformación. La diferencia con quien mide el uso es la misma que hay entre saber y suponer.
Queda una cuestión de responsabilidad, que es la que más a menudo decide si la medición existe o no. El equipo del proyecto mide hasta que el proyecto termina, y después se disuelve. Por eso la medición del valor tiene que pertenecer al directivo que responde del beneficio, con una fecha de revisión fijada para después del cierre del proyecto, normalmente a los seis y a los doce meses. Si esa fecha no está en la agenda de nadie, nadie medirá.
Aprendizaje de doble bucle de Argyris: cuándo corregir la ejecución, rediseñar o revertir la decisión
Chris Argyris y Donald Schön distinguieron en los años setenta dos formas de aprender de los errores. En el aprendizaje de bucle simple, la organización compara el resultado con el objetivo y, si no coinciden, corrige las acciones: lo hace mejor. En el aprendizaje de doble bucle, además, cuestiona los supuestos y los objetivos que justificaron esas acciones: se pregunta si lo que estaba intentando hacer era lo correcto. La idea es sencilla, y su consecuencia para una transformación es profunda: a veces no hace falta implantar mejor el cambio, sino cambiar el propio diseño.
La empresa del ejemplo ofrece un caso de manual. Ante el aumento de las reaperturas, la respuesta de bucle simple es formar mejor a los agentes en el cierre de casos, y eso fue lo que se hizo durante tres meses. La respuesta de doble bucle es preguntarse si era correcto tratar las averías repetidas como casos estándar, y la respuesta era que no. Argyris observó que las organizaciones, y en particular las personas con más éxito en ellas, tienden a refugiarse en el bucle simple, porque el doble bucle obliga a reconocer que la decisión original fue errónea. Y cuanto más se ha invertido, más difícil resulta reconocerlo: es lo que la investigación sobre la escalada del compromiso, iniciada por Barry Staw en 1976, documentó una y otra vez.
Revisión de supuestos: cómo comprobar si el diseño se apoyaba en hipótesis correctas
El doble bucle deja de ser una actitud y se convierte en un procedimiento cuando se aplica a la lista de supuestos que el diagnóstico tenía que dejar escrita. En cada punto de decisión se revisa cada supuesto y se marca como confirmado, refutado o todavía no comprobado, y un supuesto refutado obliga a revisar todas las decisiones de diseño que se apoyaban en él. En la empresa del ejemplo, la revisión a los seis meses habría sido así:
| Supuesto del diseño | Evidencia a los seis meses | Estado | Decisión de diseño afectada |
| El ahorro de tiempo de atención reducirá el plazo total | El plazo total apenas baja; la espera de piezas y aprobaciones sigue igual | Refutado | Rediseñar el circuito de aprobaciones, que era la alternativa descartada |
| Las averías repetidas son casos estándar | Las reaperturas suben del 8 % al 13 %, concentradas en ellas | Refutado | Revisión humana a partir de la tercera avería en el mismo equipo |
| La comprobación de garantía puede eliminarse | Más de cien reparaciones al mes facturadas en garantía | Refutado | Validación automática previa a la propuesta de resolución |
| Los agentes aceptarán las propuestas solo tras revisarlas | Tasa de aceptación del 97 %, también en casos con error conocido | Refutado | Casos de control y revisión de la calidad de la supervisión |
| La clasificación automática de casos sencillos es fiable | Error inferior al 2 % en la muestra revisada | Confirmado | Se mantiene y puede subir de nivel de autonomía |
La tabla muestra algo que conviene subrayar: el doble bucle no conduce necesariamente a abandonar la transformación. En el ejemplo, la clasificación de casos sencillos funcionaba y debía mantenerse, y lo que fallaba eran cuatro supuestos concretos que podían corregirse. Revisar los supuestos no es dudar de todo, sino saber exactamente qué parte del diseño se sostiene y cuál no.
Consolidar, ajustar, rediseñar o revertir: criterios para cada decisión
Cada punto de decisión de la metodología termina en una de cuatro salidas, y los criterios para elegir entre ellas deberían estar escritos antes de que lleguen los datos, para que no los elija el calendario ni la reputación de quien patrocinó el proyecto. La tabla siguiente propone esos criterios, y su utilidad es precisamente que obliga a decidir en frío qué resultado llevaría a cada salida.
| Decisión | Cuándo procede | Qué implica |
| Consolidar | Los resultados mejoran frente a la línea base, los contraindicadores se mantienen y las capacidades no se deterioran | Institucionalizar en roles, procesos, indicadores e incentivos; retirar los sistemas paralelos con pruebas |
| Ajustar la implantación | El diseño se sostiene, pero la adopción tiene bloqueos identificados en el diagnóstico por colectivos | Intervenciones dirigidas por colectivo; nueva revisión en un plazo corto |
| Rediseñar | Uno o varios supuestos del diseño están refutados, aunque el objetivo siga siendo válido | Volver al segundo nivel para las partes afectadas, manteniendo lo que funciona |
| Revertir o detener | El objetivo ya no es válido, o el valor esperado ya no compensa el coste y el riesgo de seguir | Ejecutar el plan de marcha atrás, documentar lo aprendido y proteger a quienes lo advirtieron |
La cuarta salida es la que más cuesta y la que más protege a la empresa. Revertir no tiene por qué ser un fracaso si se ha previsto: si el plan de marcha atrás existe, si las capacidades anteriores se han conservado durante un periodo de transición y si la decisión se toma con la evidencia que se acordó al principio. Una organización que es capaz de detener una iniciativa a tiempo puede permitirse experimentar mucho más que una que no lo es, porque cada experimento le cuesta menos. Y la última columna de esa fila incluye una obligación que casi nunca se cumple: reconocer públicamente a quienes advirtieron del problema, porque es la única forma de que la próxima vez alguien vuelva a hacerlo.
Hoja de ruta de la transformación empresarial: seis fases con entregables y puntos de decisión
Los cuatro niveles de la metodología describen qué hay que resolver; una hoja de ruta describe en qué orden se recorre en la práctica, y por eso cada fase indica en la primera columna el nivel al que pertenece. La que sigue tiene seis fases, numeradas desde cero porque la primera ocurre antes de que el programa exista formalmente, y cada una termina en un punto de decisión con unos entregables mínimos y una pregunta que alguien con autoridad tiene que responder. La duración de cada fase depende del tamaño y del riesgo de la transformación, y por eso no se indica: un rediseño de la atención al cliente de una empresa mediana puede recorrerlas en unos meses, y la sustitución de un ERP central en un grupo multinacional, en varios años.
| Fase | Qué se hace | Entregables mínimos | Pregunta del punto de decisión |
| 0. Preparar la decisión Nivel 1 | Nombrar al patrocinador y al dueño del beneficio, acotar el alcance y formar el equipo de diagnóstico | Mandato firmado, alcance, equipo con dedicación real | ¿Tenemos a las personas y la autoridad para responder a las cinco preguntas? |
| 1. Diagnosticar Nivel 1 | Análisis causal, trabajo de campo, línea base, inventario de dependencias y controles | Problema formulado, línea base, inventario, supuestos, caso de transformación | ¿Merece la pena cambiar, y qué alternativa elegimos? |
| 2. Diseñar Nivel 2 | Modelo operativo futuro, derechos de decisión, reparto entre personas y tecnología, incentivos | Procesos de punta a punta, matriz de decisión, niveles de autonomía, plan de capacidades | ¿Pasa el diseño las cuatro pruebas de diseño y es viable construirlo? |
| 3. Pilotar Niveles 3 y 4 | Probar en condiciones reales, con casos complejos y excepciones, frente a un grupo de comparación | Resultados del piloto, diagnóstico ADKAR por colectivos, revisión de supuestos | ¿La evidencia confirma la hipótesis lo suficiente para escalar? |
| 4. Desplegar por oleadas Nivel 3 | Extender por unidades con criterios de arranque, soporte en el puesto y plan de marcha atrás | Criterios de arranque cumplidos por oleada, cuadro de mando de tres capas | ¿Cada oleada se estabiliza antes de lanzar la siguiente? |
| 5. Consolidar y capturar valor Nivel 4 | Comparar con la línea base, institucionalizar lo que funciona, retirar sistemas paralelos | Informe de valor a seis y doce meses, decisión de consolidación, lecciones | ¿Consolidamos, ajustamos, rediseñamos o revertimos? |
Dos reglas evitan que la hoja de ruta se convierta en una cascada burocrática. La primera es que los puntos de decisión son pocos y se toman con evidencia, no con firmas: si para avanzar hay que pedir permiso dos o tres veces, la hoja de ruta funciona; si hay que pedirlo catorce, es el proceso de siempre con nombres nuevos. La segunda es que las fases se solapan entre unidades: mientras la primera oleada consolida, la tercera puede estar todavía en piloto, y lo que aprende la primera debería llegar a tiempo para cambiar el diseño de la tercera.
Cómo aplicar esta metodología en una empresa de 50 empleados sin crear una oficina de transformación
Todo lo anterior se ha ilustrado con una empresa de 450 personas en atención y planificación, porque a esa escala se ven con claridad todas las piezas. Pero muchas de las empresas que se plantean una transformación tienen entre treinta y cien trabajadores, y para ellas la pregunta práctica es otra: cómo aplicar el método sin crear una estructura que no pueden pagar ni necesitan. En una empresa pequeña se reducen los papeles, los documentos y los plazos, pero no las decisiones: las cinco preguntas y los cuatro niveles son los mismos. Y la empresa pequeña tiene una ventaja que conviene aprovechar: entre quien decide y quien hace el trabajo hay una o dos capas, no seis, y eso permite diagnosticar, decidir y corregir mucho más deprisa.
Supongamos una empresa de mantenimiento como la del ejemplo, pero con 50 personas, de las que ocho atienden y planifican unos 1.500 avisos al mes, y que se plantea automatizar con IA la recepción y la clasificación de los avisos. Las cifras vuelven a ser ilustrativas. Para aplicar la metodología le bastan cinco elementos:
- Un patrocinador, normalmente el gerente o el director general, que responde también del beneficio: decide, resuelve los conflictos entre áreas y reserva tiempo real para el equipo.
- Un propietario del proceso, la persona que mejor conoce el circuito de avisos de punta a punta, a menudo la responsable de planificación, que decide sobre el diseño y responde de la calidad del proceso nuevo.
- Un equipo pequeño, de dos o tres personas más con una dedicación explícita, por ejemplo un día a la semana durante el diagnóstico y el diseño, que incluya a alguien que hace el trabajo cada día y, si hace falta, un apoyo técnico interno o externo.
- Un piloto representativo: un tipo de aviso o una zona durante seis u ocho semanas, con casos complejos y excepciones, comparado con el resto de la operación, que sigue con el proceso anterior.
- Tres o cuatro indicadores fundamentales: uno de resultado, como el plazo de resolución de punta a punta; un contraindicador, como las reaperturas o las quejas; uno de capacidad, como el acierto de quien más sabe en los casos difíciles o el tiempo que tarda una persona nueva en resolverlos sola; y, solo como diagnóstico, uno de adopción.
La tabla resume qué se simplifica respecto a un programa grande. Lo que cambia es la forma de cada herramienta, no la decisión que la herramienta sirve para tomar.
| Elemento | En un programa grande | En una empresa de 50 personas |
| Gobierno | Comité de dirección, oficina de transformación y comités específicos | El gerente y el propietario del proceso, con una reunión de decisión breve cada dos semanas |
| Diagnóstico | Decenas de entrevistas, seguimiento de casos y minería de procesos | Dos o tres días siguiendo casos reales con quienes los atienden y una línea base de tres meses en una hoja |
| Caso de transformación | Documento formal revisado en cada punto de decisión | La plantilla en una página, con el destino de la capacidad liberada y los criterios para parar |
| Derechos de decisión | Matriz completa por proceso | Las cinco o seis decisiones que de verdad generan dudas, con quién decide y en qué plazo |
| Adopción | Diagnóstico ADKAR por colectivos con evidencias | Una conversación con cada persona afectada y la observación directa del trabajo durante el piloto |
| Medición | Cuadro de mando de tres capas y comparación por oleadas | Tres o cuatro indicadores, comparados con la línea base y con la parte de la operación que no entró en el piloto |
| Hoja de ruta | Varias oleadas, a lo largo de meses o años | Un piloto y una extensión al resto, normalmente en unos pocos meses |
Hay tres cosas que una empresa pequeña no puede saltarse, y que son las primeras que se caen por falta de tiempo. La primera es la línea base: si los sistemas no registran los datos, se miden a mano durante unas semanas antes de cambiar nada, porque después ya no se podrá. La segunda es el inventario de controles informales, que en una empresa de cincuenta personas es todavía más crítico que en una grande, porque el conocimiento se concentra en dos o tres personas y basta con que una de ellas se marche, o con que se automatice lo que hacía, para que desaparezcan controles que nadie había escrito. La tercera son los criterios para parar, escritos antes del piloto. Una empresa de cincuenta personas no necesita una oficina de transformación; necesita que alguien con autoridad haga las preguntas correctas en el momento adecuado y que alguien que conoce el trabajo las responda.
Preguntas para el comité de dirección: qué exigir antes de cada decisión y qué señales de alarma vigilar
Un comité de dirección no necesita dominar cada marco de este artículo para gobernar bien una transformación. Necesita exigir lo correcto en los cuatro momentos en que de verdad se decide algo, que coinciden con el final de cada nivel de la metodología, y vigilar las señales que indican que algo se tuerce cuando todavía es barato corregirlo. La tabla no añade un marco nuevo: es la columna de decisiones del mapa de la metodología, convertida en lo que hay que poder demostrar antes de firmar.
| Momento de decisión | Qué debe poder demostrarse | Señales de alarma |
| Aprobar la inversión Final del nivel 1 | El problema formulado sin nombrar la solución; una línea base por tipo de caso; al menos tres alternativas comparadas, incluida una mejora gradual; los supuestos escritos; el destino de la capacidad que se libere; los criterios para parar; un dueño del beneficio con nombre | El objetivo del programa contiene el nombre de una tecnología; el caso de negocio solo se compara con no hacer nada; el ahorro se calcula multiplicando minutos por el coste de una hora |
| Construir el diseño Final del nivel 2 | Un diseño hecho sobre el trabajo real; una decisión para cada control informal; un único decisor para cada decisión y plazos de escalado; un nivel de autonomía para cada acción automatizada; incentivos coherentes con el nuevo modelo | Nadie del equipo ha seguido un caso completo con quien lo ejecuta; desaparece una hoja paralela sin que nadie pregunte para qué servía; los mandos siguen evaluados con los indicadores anteriores |
| Escalar después del piloto Final del nivel 3 | Un piloto con casos complejos y excepciones, comparado con un grupo sin el cambio; los bloqueos de adopción identificados por colectivos; las objeciones documentadas, investigadas; un plan de marcha atrás probado | Las objeciones se responden con más formación y nunca con una investigación; las victorias tempranas no tienen línea base; bajan las incidencias comunicadas mientras la operación empeora |
| Consolidar Final del nivel 4 | Resultados mejores que la línea base y atribuibles al cambio; contraindicadores estables; capacidades expertas medidas y conservadas; supuestos revisados; sistemas paralelos retirados después de comprobar qué contenían | El indicador que revisa la dirección es el porcentaje de uso; el cambio se institucionaliza antes de tener datos de resultado; nadie tiene en la agenda la revisión a los seis y a los doce meses |
Un elemento de la segunda columna sin respuesta clara no es un detalle pendiente, sino una decisión que todavía no se puede tomar; una señal de la tercera no prueba que la transformación esté fracasando, pero es una razón para investigar antes de seguir. Para el arranque formal del proyecto, el artículo sobre cómo arrancar un proyecto de transformación desarrolla en detalle las fases cero y uno e incluye una lista de cuarenta preguntas para el kickoff.
La empresa del ejemplo habría encendido alarmas en las cuatro filas, y ninguna por incompetencia. Cada decisión fue razonable con la información que se tenía; el problema fue que el método no obligaba a buscar la información que faltaba. Esa es la razón de ser de una metodología: no añadir listas, sino obligar a la organización a hacerse las preguntas que de otro modo no se haría.
Conclusión: de gestionar el cambio a transformar la empresa
La empresa de servicios con la que empezaba este artículo terminó corrigiendo su transformación. Rediseñó el circuito de aprobaciones y de piezas, que era donde estaba la mayor parte del plazo; devolvió las averías repetidas a una revisión humana; convirtió la comprobación de garantía en una validación automática; dio a las coordinadoras veteranas la responsabilidad de los casos complejos y de la formación de los nuevos; y cambió el indicador que la dirección revisaba cada semana, del porcentaje de uso a la resolución de punta a punta. La plataforma de IA siguió en su sitio, pero dejó de ser el objetivo y pasó a ser una pieza del diseño. Todo eso podía haberse hecho antes del arranque, con un diagnóstico que mirase el trabajo real y un cuadro de mando que midiese algo más que la adopción.
La lección no es que los modelos de gestión del cambio estén equivocados. Kotter, ADKAR y Lewin son marcos muy extendidos y útiles para movilizar a una organización, conseguir que las personas adopten nuevas formas de trabajar y evitar que vuelvan a las anteriores, siempre que se conozcan sus límites y no se espere de ellos una garantía de éxito que ninguno ofrece. La lección es que esas herramientas resuelven una de las cinco preguntas de una transformación, y que una empresa que solo dispone de ellas puede implantar con éxito un cambio equivocado. Las otras cuatro, por qué cambiar, qué cambiar, cómo construirlo y cómo saber si fue una buena decisión, necesitan diagnóstico, diseño organizativo, gestión de proyectos y medición del valor, y necesitan, sobre todo, la disposición a corregir las decisiones iniciales cuando los datos lo piden.
La frase que mejor resume la diferencia entre las dos cosas es esta: la gestión del cambio consigue que las personas trabajen de una manera diferente; la transformación empresarial tiene que garantizar, además, que esa nueva manera de trabajar crea más valor que la anterior. El éxito no consiste en conseguir que una organización acepte el futuro que se ha diseñado para ella, sino en asegurarse de que se ha diseñado un futuro mejor y en comprobar, con datos, que de verdad se está consiguiendo. Quien quiera ver lo que ocurre cuando falta esa comprobación tiene un catálogo detallado en el análisis de los grandes errores al implantar la inteligencia artificial.
Si hubiera que llevar este artículo a una reunión de comité en un solo párrafo, sería este:
Adoptar un cambio no demuestra que fuera el cambio correcto. Una transformación tiene que responder a cinco preguntas: por qué cambiar, qué cambiar, cómo construirlo, cómo conseguir que funcione y cómo saber si fue una buena decisión. Los modelos de gestión del cambio, como Kotter, ADKAR o Lewin, ayudan sobre todo con la cuarta y dicen poco de las demás. Por eso, antes de aprobar, exigimos un problema formulado sin la solución, una línea base y unos criterios escritos para parar; antes de arrancar, un diseño hecho sobre el trabajo real, con un único decisor para cada decisión y los controles informales inventariados; y antes de consolidar, evidencia de que el negocio ha mejorado frente a la línea base sin perder capacidades. Lo que no se consolida por adopción, sino por valor, puede corregirse a tiempo.
Para profundizar en algunas piezas que este artículo solo resume, estas lecturas del blog son un buen punto de partida:
- Enamórate del problema, no de la solución, sobre el primer nivel de la metodología.
- Reingeniería de procesos con IA agéntica: casos de antes y después, sobre el rediseño del trabajo antes de automatizar.
- Organizaciones artificiales: por qué la IA no está mejorando tus decisiones, sobre la supervisión humana y el criterio experto.
- Fracasos en la implantación de ERP, sobre lo que ocurre cuando las decisiones de diseño se aplazan hasta la puesta en marcha.
En Transformalix trabajamos precisamente en ese espacio: el diagnóstico del trabajo real, el diseño del modelo operativo, la implantación y la medición del valor, como partes de un mismo programa y no como encargos separados. Si su organización está a punto de aprobar una transformación, o lleva meses implantando una cuyos resultados no llegan, podemos ayudarle a responder las cinco preguntas antes de que las responda el calendario. Hablemos.
