IA soberana: la responsabilidad sigue en la empresa
Eva Mickler
7 min. lectura Quien adopta un modelo de IA en producción asume la responsabilidad de su comportamiento, ...
Leer artículo
7 min de lectura
La mayoría de las reorganizaciones desplazan cajas y no cambian nada. El 63 por ciento de los rediseños de modelos operativos alcanza hoy sus objetivos; hace diez años eran el 21 por ciento. La diferencia la marca la lógica operativa subyacente: quién puede tomar qué decisión, quién ostenta el mandato de plataforma y cómo se regulan las interfaces. Quien deja estas tres preguntas abiertas construye la antigua fricción dentro de la nueva estructura.
Lo más importante en resumen
- El organigrama es el síntoma, no la solución. Las reorgs redibujan líneas, pero dejan intactos los derechos de decisión, los mandatos y las interfaces. Ahí es exactamente donde surge la fricción que desencadena la siguiente reorg.
- Tres palancas sostienen el modelo. Unos derechos de decisión claros, un mandato de plataforma real y una gobernanza vinculante de interfaces determinan el ritmo y la creación de valor. Sin ellos, cualquier estructura es solo otra forma de parálisis.
- Entre el 20 y el 30 por ciento del rendimiento del capital está en juego. Según McKinsey, eso es lo que pierden las organizaciones en potencial de rendimiento del capital por un modelo operativo mal alineado. El impacto se traslada directamente a la rentabilidad.
Relacionado:Gobernanza de la IA: por qué los CEO no pueden delegar / El 20 por ciento de las empresas obtiene el 74 por ciento del rendimiento de la IA
Por qué la reorg suele ser la herramienta equivocada
Una reorganización es la respuesta más visible a un problema invisible. Se puede anunciar, mostrar en diapositivas y medir en trimestres. Por eso los equipos directivos recurren a ella por reflejo cuando el rendimiento falla. Cambiar el organigrama da la sensación de estar actuando.
El efecto se disipa porque la fricción rara vez reside entre las cajas. Reside en las transiciones. ¿Quién puede tomar una decisión de arquitectura sin pasar por tres niveles de escalada? ¿Quién asume el presupuesto de una plataforma compartida que no pertenece a nadie en exclusiva? Ahí es donde una organización pierde velocidad, no en el número de niveles jerárquicos.
¿Qué es un modelo operativo? El modelo operativo describe cómo una organización genera valor: quién toma qué decisiones, cómo fluye el trabajo entre unidades, qué plataformas se comparten y con qué se mide el éxito. Es la lógica operativa que subyace al organigrama, y determina si una estructura sostiene o simplemente tiene otro aspecto.
McKinsey ha aportado cifras sólidas al respecto. Más de 2.000 directivos señalan que los modelos operativos mal alineados cuestan entre el 20 y el 30 por ciento del potencial de rendimiento del capital. La buena noticia del mismo estudio: la tasa de éxito de los rediseños ha aumentado del 21 al 63 por ciento. La palanca no fue más estructura, sino una mejor alineación de los responsables de decisión y una transformación consecuente de los procesos clave.
Tres palancas que determinan la aportación de valor
La primera palanca son los derechos de decisión. En la mayoría de las organizaciones no está definido quién puede tomar una decisión de forma autónoma y quién solo debe ser consultado. El resultado es una cultura de cobertura: cada resolución sube hacia arriba, cada conflicto se convierte en asunto del jefe. Un Operating Model que funciona fija los derechos de decisión de forma explícita, hasta la cuestión de qué decisión técnica puede tomar un equipo de plataforma sin consultar. Donde esto falta, también fracasa la Enterprise Agility ante la primera escalada real.
La segunda palanca es el mandato de plataforma. Las plataformas compartidas -desde la base de datos hasta el stack interno de desarrollo- rara vez fracasan por la tecnología. Fracasan porque nadie tiene el mandato de fijar estándares vinculantes. Un equipo de plataforma sin mandato se convierte en un solicitante que negocia cada integración por separado. Con mandato, se convierte en el definidor de estándares, cuya decisión por defecto es válida mientras ninguna unidad de negocio demuestre un caso especial documentado. Precisamente este desplazamiento separa una plataforma escalable de un costoso proyecto paralelo, tal como se aprecia también en el salto del piloto de IA a la operación regular.
La tercera palanca es la gobernanza de interfaces. Cada reorganización genera nuevos puntos de transferencia entre unidades. Si quedan sin regular, la fricción antigua simplemente se desplaza a un nuevo lugar. Las interfaces vinculantes definen lo que una unidad debe a la otra: qué datos, con qué calidad y para cuándo. Suena burocrático, pero es exactamente lo contrario. Las transferencias claras reducen los traspasos, el trabajo duplicado y los bucles de coordinación, es decir, precisamente la fricción que McKinsey identifica como palanca central en el rediseño.
Quien redibuja el organigrama y olvida los derechos de decisión tendrá la misma fricción en otro lugar 18 meses después.
El dato que marca la dirección
Del 21 al 63 por ciento. Así de fuerte ha aumentado la tasa de éxito de los rediseños de Operating Model en una década. El motor estuvo en unos derechos de decisión claros, en un trabajo de procesos bien invertido y en un mandato que hace vinculantes los estándares.
El factor DACH: cogestión, matriz y SAP
En el contexto alemán, el modelo choca con tres realidades. La primera es la cogestión. Quien redistribuye los derechos de decisión y hace vinculantes las interfaces toca modificaciones organizativas en las que el comité de empresa debe participar. Eso no solo ralentiza, también disciplina: un mandato que ha pasado por la representación de los trabajadores resiste mejor la primera presión.
La segunda realidad es la matriz consolidada. Muchos grupos del espacio DACH arrastran una doble línea de reporte -región y función- que socava cualquier asignación clara de decisiones. Un Operating Model que funcione aquí no tiene que eliminar la matriz, pero sí debe establecer para cada tipo de decisión qué eje tiene prioridad. De lo contrario, el derecho de decisión no pasa de ser una promesa en papel.
La tercera es el núcleo centrado en SAP. Cuando un único sistema ERP dicta la lógica de los procesos, la gobernanza de interfaces no es una elección libre, sino que está ligada a la realidad del sistema. Es una limitación, pero también un ancla: donde los procesos ya están configurados en el sistema, las transferencias pueden definirse con mayor precisión que en un entorno de herramientas dispersas. Además, quien regula las interfaces con rigor necesita talento tecnológico con perfil de interfaces, no solo profundidad de especialidad.
La contraposición: A veces la estructura realmente debe rehacerse
Se puede objetar que hay situaciones en las que solo un verdadero corte estructural sirve de ayuda. Tras una fusión, en un carve-out o cuando un modelo de negocio colapsa, ajustar los derechos de decisión no es suficiente. Es cierto. Sin embargo, la objeción confunde el motivo con el método. Incluso un corte estructural necesario solo se sostiene si se accionan los tres palancas al mismo tiempo. Quien redibuja el organigrama sin aclarar los derechos de decisión, el mandato de plataforma y las interfaces tendrá la misma fricción en otro lugar 18 meses después. El mecanismo también se observa con la IA: según BCG, las organizaciones que transforman en profundidad sus flujos de trabajo extraen significativamente más valor de la tecnología que aquellas que se limitan a proyectos piloto aislados.
El primer paso en los próximos 90 días
No tocar el organigrama, sino enumerar las diez decisiones recurrentes más importantes. Para cada una, responder a la pregunta: ¿quién decide solo, quién es consultado, quién es simplemente informado? Ya este paso pone de manifiesto dónde las decisiones ascienden innecesariamente hacia arriba. En paralelo, identificar las tres interfaces más costosas entre unidades y establecer por escrito qué debe cada una a las demás. Solo cuando estas dos listas estén listas tiene sentido plantearse la cuestión de la estructura. En la mayoría de los casos se comprueba entonces que la reorganización no era necesaria en absoluto, porque el problema real residía en las transiciones, no en los recuadros. Quien trabaje con rigor en este punto también evitará la próxima reorganización, pues la capacidad de cambio es más limitada de lo que la hoja de ruta presupone.
Preguntas frecuentes
¿Por qué fracasan tantas reorganizaciones?
Porque cambian el organigrama pero dejan intacta la lógica operativa subyacente. La fricción real reside en los derechos de decisión, en la falta de un mandato de plataforma y en interfaces no reguladas. Si no se mueven estos tres palancas, una reorg simplemente desplaza la antigua fricción a un nuevo lugar y fuerza la siguiente en 18 meses.
¿Qué diferencia un modelo operativo de un organigrama?
El organigrama muestra las líneas de reporte, es decir, quién depende de quién. El modelo operativo describe la lógica de funcionamiento: quién puede tomar qué decisión, cómo fluye el trabajo entre unidades, qué plataformas se comparten y cómo se mide la aportación de valor. Dos organizaciones con un organigrama idéntico pueden funcionar de manera completamente diferente.
¿Cuál es el primer paso concreto sin necesidad de reestructurar de inmediato?
Un inventario de las diez decisiones recurrentes más importantes junto con una asignación clara de quién decide en solitario, quién es consultado y quién simplemente es informado. Complementado con las tres interfaces más costosas entre unidades y la definición de lo que cada una debe a las demás. Estas dos listas aclaran a menudo más que un nuevo organigrama.
Más para leer en Digital Chiefs
Digital ChiefsPuerta de Oro: Apple convierte la inteligencia artificial en un fosoDigital ChiefsEl mercado mundial se fragmenta: la fortaleza de Europa se convierte en trampaDigital ChiefsLa inteligencia artificial ha destruido la actitud: lo que ahora importaMás de la red MBF Media
cloudmagazinKubernetes como sistema operativo por defecto para IA: el clúster como cuestión de cumplimiento mybusinessfutureAgentes de IA en el equipo: por qué solo uno de cada nueve pilotos llega a producción securitytodayDORA y NIS2: por qué las auditorías bancarias colisionan ahoraFuente de la imagen: generada por IA (junio de 2026), certificado C2PA integrado en la imagen