Causas Estructurales vs. Técnicas del Fracaso en la Transformación Digital

Dr. Darren W. Pulsipher
Serie: Por qué la Transformación Digital Falla — y por qué existe O-DXA

La transformación digital ha estado en las agendas de los ejecutivos durante más de dos décadas.
A lo largo de ese tiempo, las organizaciones han pasado por generaciones sucesivas de tecnología:
ERP en las instalaciones, arquitecturas orientadas a servicios, plataformas en la nube, automatización, analítica, IA.

Con cada ola, las herramientas mejoran.
Sin embargo, los resultados de la transformación se ven extrañamente familiares.

• Los proyectos entran en funcionamiento.
• Los pilotos tienen éxito.
• Los paneles de control se iluminan.

Y luego—tres a cinco años después—la organización se encuentra lanzando una nueva iniciativa de “transformación” para abordar muchos de los mismos problemas que se suponía que la anterior iba a resolver.

Esta no es una historia aislada.
Es un patrón.

La Conferencia 1 de esta serie enmarcó ese patrón como persistente y sistémico:
un fracaso que recurre a través de sectores, tecnologías y cambios de liderazgo.
En esta entrega, vamos un paso más allá:
examinamos por qué las explicaciones centradas en la tecnología no son suficientes,
y por qué las causas principales del fracaso son estructurales y arquitectónicas, no técnicas.

Nuestro objetivo es distinguir las causas estructurales de los síntomas técnicos,
y mostrar cómo la desalineación entre estrategia, ejecución y gobernanza mantiene estancados los resultados de la transformación digital—sin importar qué herramientas compres.

Cuando Mejores Herramientas No Solucionan el Patrón

Cuando los esfuerzos de transformación se estancan, el post-mortem a menudo suena familiar:

• “Elegimos la plataforma incorrecta.”
• “El proveedor no cumplió.”
• “La metodología no fue un buen ajuste para nuestra cultura.”
• “El equipo no tenía las habilidades adecuadas.”

Estas no son quejas ficticias.
Describen problemas reales que pueden descarrilar un proyecto.

El problema no es que estas explicaciones sean falsas.
El problema es que, tomadas solas, son demasiado pequeñas para explicar el patrón.

Considera cómo se repiten los fracasos de la transformación digital:

• A través de diferentes generaciones de tecnología
  (ERP monolítico a SOA a microservicios a nube a IA).
• Con diferentes proveedores y socios
  (cambiando de proveedores, firmas consultoras o plataformas en cada nueva ola).
• Bajo diferentes equipos de liderazgo
  (los CIO, directores digitales o patrocinadores de programas vienen y van).

Si la causa raíz fuera “la plataforma incorrecta” o “el socio equivocado”,
esperarías que los resultados se vieran diferentes una vez corregidas esas elecciones.
En cambio, las organizaciones a menudo experimentan:

• Los mismos retrasos en la toma de decisiones.
• La misma dificultad para escalar más allá de los pilotos.
• La misma tensión entre la optimización local y los resultados empresariales.

En otras palabras:
el patrón observable no es específico de los proveedores y no es específico de las herramientas.

Las explicaciones técnicas—errores de configuración, herramientas inmaduras, cobertura de pruebas deficiente, prácticas de DevOps débiles—son reales.
Pueden hundir un solo proyecto.

Pero no pueden, por sí solas, explicar por qué fracasos materialmente similares se presentan a través de
múltiples generaciones de tecnología, en múltiples organizaciones, a lo largo de décadas.

Cuando diferentes herramientas producen los mismos resultados estructurales, la estructura es lo que necesitas investigar.

Por qué los Post-Mortem Técnicos Siguen Perdiendo el Punto

Los post-mortem técnicos son atractivos porque se sienten concretos:

• Puedes señalar un sistema mal configurado.
• Puedes rastrear una caída a una elección de diseño particular.
• Puedes atribuir sobrecostos a una complejidad subestimada.

Estas narrativas son importantes para el aprendizaje y la mejora.
Pero tienen dos puntos ciegos incorporados.

1. Se Centran en Condiciones Locales

Los análisis técnicos se centran en el entorno local de un proyecto o sistema:

• La pila específica, infraestructura o arquitectura.
• El equipo específico y sus prácticas.
• El ciclo de vida y restricciones de entrega específicos.

Rara vez preguntan:
¿Qué sobre el sistema circundante hizo que este resultado fuera probable?

Por ejemplo:

• ¿Por qué los derechos de decisión se ubicaron donde estaban?
• ¿Por qué las aprobaciones de financiamiento se estructuraron de la manera en que lo hicieron?
• ¿Por qué los foros de gobernanza refuerzan comportamientos en silos en lugar de resultados interfuncionales?

Sin estas preguntas, cada fallo se trata como una anomalía localizada
en lugar de como evidencia de un patrón estructural compartido.

2. Se Reinician con Cada Nueva Ola de Tecnología

Los post-mortem técnicos a menudo están “bloqueados en versión” a una pila particular:

• “Aprendimos que no debemos diseñar monolitos de esa manera.”
• “No cometeremos ese error con nuestra próxima migración a la nube.”
• “Nuestro próximo proyecto de IA incluirá MLOps desde el principio.”

Pero luego llega una nueva ola.
Nuevos patrones, nuevas palabras de moda, nuevas restricciones.

La organización “reinicia” su aprendizaje en torno a la nueva pila,
mientras conserva muchas de las mismas restricciones estructurales:

• La misma gobernanza fragmentada.
• Los mismos modelos de financiamiento en silos.
• Los mismos incentivos desalineados.

La tecnología cambia.
La estructura no.
Y así, el resultado— a nivel empresarial—permanece igual.

Lo que “Estructura” Realmente Significa en la Transformación Digital

Para entender las causas estructurales del fracaso,
necesitamos ser precisos sobre lo que estructura significa en este contexto.

La estructura no es una metáfora.
Es el conjunto de disposiciones duraderas que configuran cómo se realiza realmente el trabajo.

Como mínimo, esa estructura incluye:

• Derechos de decisión
  ¿Quién puede decidir qué, a qué nivel y en qué marco de tiempo? Por ejemplo:

  • ¿Puede un equipo interfuncional cambiar un proceso crítico, o debe escalarlo a un comité directivo?
  • ¿Quién posee decisiones que abarcan múltiples unidades de negocio?

• Modelos de financiamiento
  ¿Cómo se proponen, aprueban y renuevan las inversiones?
  ¿Los presupuestos:

  • Siguen proyectos, departamentos, plataformas o flujos de valor?
  • Soportan ajustes continuos, o solo programas grandes y episódicos?

• Foros de gobernanza
  ¿Dónde se resuelven las cuestiones transversales?

  • ¿Existen mecanismos para equilibrar la autonomía local con la coherencia empresarial?
  • ¿Los órganos de riesgo y cumplimiento se integran con la entrega digital, o existen como puertas de acceso seriales?

• Flujos de valor y trabajo
  ¿Cómo se mueve el trabajo a través de las fronteras?

  • ¿Los procesos están diseñados en torno a los recorridos del cliente y los resultados de la misión,
    o en torno a organigramas?
  • ¿Dónde los traspasos crean fricción o modos de fallo?

Estos elementos de la estructura operan tanto por encima como alrededor de cualquier pila de tecnología particular.
Forman:

• Qué proyectos se financian.
• Qué compensaciones son aceptables.
• Qué tan rápido la intención estratégica puede fluir hacia decisiones ejecutables.

Cuando decimos que el fracaso de la transformación es estructural, queremos decir:

Los arreglos de derechos de decisión, financiamiento, gobernanza y flujos de valor
sistemáticamente alejan la ejecución de la estrategia declarada—incluso cuando los proyectos individuales son técnicamente exitosos.

Desalineación Estructural: Estrategia, Ejecución, Gobernanza

Una forma de ver las causas estructurales más claramente es observar cómo
la estrategia, ejecución y gobernanza se distancian entre sí.

• Estrategia — las declaraciones de intención y dirección:

  • “Seremos una organización impulsada por datos.”
  • “Entregaremos servicios digitales integrales y sin fisuras.”
  • “Empoderaremos a los equipos cercanos a la misión.”

• Ejecución — el trabajo real:

  • Programas, proyectos y productos.
  • Procesos y flujos de trabajo diarios.
  • Cómo se dota y mide a los equipos.

• Gobernanza — las reglas y mecanismos de supervisión:

  • Políticas de riesgo y cumplimiento.
  • Procesos de presupuesto y cartera.
  • Estándares y puertas de aprobación.

Cuando los esfuerzos de transformación flaquean, a menudo se ven patrones como:

• La estrategia promete servicios transversales y centrados en el usuario.
  La ejecución sigue organizada en torno a proyectos departamentales.
  La gobernanza revisa propuestas departamento por departamento.

• La estrategia exige equipos empoderados y ágiles.
  Los equipos de ejecución adoptan terminología ágil.
  La gobernanza aún requiere ciclos de aprobación de varios meses para cambios básicos.

• La estrategia enfatiza decisiones impulsadas por datos.
  Los equipos de ejecución construyen paneles de analítica.
  Los procesos de gobernanza aún dependen de informes estáticos y aprobaciones manuales.

En cada caso:

• La tecnología puede ser moderna.
• Las prácticas de entrega pueden estar actualizadas.

Pero la relación estructural entre estrategia, ejecución y gobernanza está desalineada.
Y esa desalineación es lo que finalmente bloquea la transformación sostenida.

Cuando las estructuras están desalineadas:

• Los equipos de ejecución pueden ser eficientes y capaces—mientras optimizan para las cosas equivocadas.
• Los foros de gobernanza pueden ser diligentes—mientras refuerzan los silos y ralentizan el cambio sistémico.
• Los documentos de estrategia pueden ser convincentes—mientras tienen poco efecto en el comportamiento diario.

El resultado es familiar:

• Victorias locales.
• Estancamiento empresarial.
• Otro programa de transformación unos años más tarde.

Cómo la Desalineación Se Amplifica con Nuevas Tecnologías

Aquí emerge una realidad contraintuitiva:

Cuando existe desalineación estructural, mejor tecnología puede agravar el problema.

¿Por qué?

Porque las herramientas modernas:

• Reducen el costo de la experimentación.
• Aumentan la velocidad de la toma de decisiones locales.
• Facilitan que equipos o departamentos individuales avancen por su cuenta.

Si la estructura circundante no está alineada:

• Los equipos se mueven rápidamente en direcciones diferentes.
• Las optimizaciones locales se multiplican.
• Aumentan los desafíos de integración y gobernanza.

En lugar de una transformación sincronizada, obtienes:

• Múltiples “plataformas estratégicas” con capacidades superpuestas.
• Implementaciones inconsistentes de políticas similares (por ejemplo, seguridad, protección de datos).
• Soluciones paralelas para el mismo problema, ninguna de las cuales escala a nivel empresarial.

La tecnología no es “mala.”
Simplemente está amplificando la estructura que encuentra.

Si los derechos de decisión, los modelos de financiamiento y los mecanismos de gobernanza están fragmentados,
las herramientas digitales modernas acelerarán la fragmentación.

Arquitectura como Disciplina Estructural, No Documentación

Aquí es donde la arquitectura entra en la historia—no como un conjunto de diagramas,
sino como una disciplina estructural.

En muchas organizaciones, la arquitectura se percibe como:

• El equipo que mantiene modelos de referencia y repositorios de estándares.
• El grupo que asiste a revisiones de diseño y dice “no” tarde en el proceso.
• Una función de documentación que se queda atrás del cambio en el mundo real.

En un marco estructural, eso no es suficiente.

La arquitectura, entendida estructuralmente, trata sobre:

• Codificar la intención estratégica en restricciones y patrones operativos
  para que las decisiones locales sumen resultados empresariales.

• Dar forma a los caminos de decisión
  para que cuando aparezca una nueva iniciativa, fluya a través de principios consistentes, no negociaciones ad hoc.

• Conectar estrategia, ejecución y gobernanza al:

  • Informar sobre cómo se estructuran las carteras.
  • Influir en cómo los modelos de financiamiento refuerzan la coherencia.
  • Proporcionar principios compartidos que los organismos de gobernanza pueden aplicar.

En otras palabras:
la arquitectura no es principalmente el artefacto; es el sistema gubernamental que
alinea personas, procesos, políticas y tecnología a lo largo del tiempo.

Sin esta capa arquitectónica operando como una disciplina estructural:

• La transformación se ejecuta como una secuencia de proyectos desconectados.
• Cada proyecto debe negociar la alineación por su cuenta.
• Los órganos de gobernanza carecen de un marco compartido para tomar decisiones inter-silos.

Los resultados se ven como “fracaso técnico,” pero el problema más profundo es:

• No existe un mecanismo estructural para mantener la ejecución atada a la estrategia a medida que cambian las condiciones.

Por qué Tratar los Problemas Estructurales como Problemas Técnicos Falla

Cuando las organizaciones diagnostican erróneamente problemas estructurales como técnicos,
tienden a responder de maneras predecibles:

• Lanzar una reestructuración mayor para “solucionar” la entrega lenta.
• Cambiar un ecosistema de proveedores por otro para “simplificar” el panorama.
• Introducir una nueva metodología o modelo operativo como la solución mágica.

Estas respuestas pueden ser valiosas en un sentido limitado.
Pueden mejorar aspectos específicos del entorno.

Pero si las estructuras subyacentes de derechos de decisión, financiamiento y gobernanza permanecen sin cambios:

• La nueva plataforma hereda los mismos cuellos de botella de aprobación y los mismos incentivos desalineados.
• El nuevo proveedor se encuentra con los mismos conflictos inter-silos que el anterior.
• La nueva metodología se adapta para encajar en los viejos ritmos de gobernanza y presupuestación.

La organización invierte fuertemente en cambio—y luego descubre que
su trayectoria es en gran parte la misma.

Dos costos específicos de diagnóstico erróneo destacan:

1. Complejidad Acumulada
   Cada ciclo suma:

   • Nuevas plataformas e integraciones.
   • Procesos de gobernanza adicionales.
   • Más capacidades superpuestas.
     La complejidad crece.
     La alineación estructural no.

2. Reducción de la Capacidad para un Cambio Estructural Real
   Después de unos pocos ciclos, los interesados se vuelven escépticos:

   • “Ya hemos realizado tres programas de transformación.”
   • “Probamos ágil/nube/analítica; no solucionó el problema.”
     El apetito por un cambio estructural más profundo disminuye,
     incluso cuando la necesidad de ello aumenta.

Hacia una Respuesta Arquitectónica Integrada (Previo)

Esta conferencia y su contraparte en el blog se han centrado deliberadamente en:

• Mostrar que el fracaso persistente indica causas sistémicas más allá de herramientas y proyectos individuales.
• Argumentar que la desalineación estructural entre estrategia, ejecución y gobernanza es un motor principal de esos fracasos.
• Re-posicionar la arquitectura como una disciplina estructural capaz de abordar esa desalineación—no como un ejercicio de documentación posterior a los hechos.

Aún no hemos descrito un marco de solución específico o un modelo operativo.
Eso vendrá más adelante en la serie.

Antes de introducir cualquier enfoque particular, necesitamos una comprensión clara y compartida de:

• Cómo se manifiesta la desalineación a través de personas, procesos, políticas y tecnología.
• Cómo la fragmentación de gobernanza y los patrones de derechos de decisión crean modos de fallo predecibles.
• Lo que significaría para la arquitectura funcionar como un genuino sistema de gobernanza.

La próxima entrega profundizará en esos patrones estructurales:
mapeando cómo los fracasos recurrentes surgen de la forma en que las organizaciones están actualmente arquitectadas,
y qué tipo de modelo arquitectónico integrado se requiere para mantener
la transformación digital alineada a lo largo del tiempo.

Por ahora, la conclusión clave es sencilla:

Si los fracasos recurrentes de transformación parecen los mismos a través de herramientas, proveedores y olas tecnológicas, el problema no es principalmente técnico.
Es estructural—y la arquitectura, tratada como una disciplina estructural, es donde debe comenzar el trabajo.