Estamos on track. Ese es el problema

Por Roberto Collado, Head of Cloud Transformation Programs, Ferrovial

 

En este tiempo ha cambiado casi todo. Hemos pasado por la primera ola de digitalización, el business intelligence, el big data, el cloud y ahora la inteligencia artificial. Han cambiado las plataformas, las arquitecturas, las metodologías y buena parte de las capacidades que tenemos a nuestra disposición. Y, sin embargo, seguimos hablando de problemas sorprendentemente parecidos.

Hay una cifra que resume bien esta paradoja: “el 70% de las transformaciones fracasan”. Lleva décadas repitiéndose y suele atribuirse a McKinsey, aunque Hughes rastreó su origen en 2011 sin encontrar evidencia empírica sólida detrás, hasta llegar a una estimación que Hammer y Champy habían calificado de “no científica” en 1993.

El porcentaje puede ser discutible. La persistencia del problema, bastante menos. Si después de varias generaciones tecnológicas seguimos describiendo dificultades similares para transformar una organización, quizá haya una parte del problema que estamos buscando en el lugar equivocado.

En organizaciones complejas, cuanto más nos alejamos de la ejecución, más limpia puede llegar la información. El board puede acabar viendo un resumen de un resumen de un resumen. No por mala fe: cada nivel simplifica razonablemente lo que recibe. Pero una cascada de simplificaciones razonables puede producir una imagen que ya no se parece al programa.

 

La tiranía del porcentaje

Todo programa acaba resumido en un porcentaje, un semáforo, un “on track / at risk” que alguien mirará durante cuarenta segundos en un comité. Es necesario, pero premia la superficie, no la profundidad. Reportar “80% completado” es fácil. Reportar “avanzamos según el plan, pero una de las hipótesis técnicas sobre las que lo construimos ya no parece sostenerse” es bastante más incómodo.

Así que la duda espera: a tener más información, al siguiente comité, a estar mejor formulada. El reporting por hitos no la esconde por malicia: está diseñado para contener estado, no incertidumbre.

Este año se cumplen cuarenta años del Big Mac Index de The Economist. Su genialidad está en usar algo sencillo y comparable para hacer visible una realidad mucho más compleja. Si tuviera que construir mi propio Big Mac Index para programas de transformación, mediría una sola cosa: cuánto tarda una duda relevante que nace en el terreno en llegar hasta alguien con autoridad real para decidir sobre ella. No cuánto tarda en registrarse como riesgo o entrar en una herramienta, sino cuánto tarda en llegar a alguien que puede hacer algo.

Un programa puede estar al 80% y tardar tres meses. Otro, al 60%, tres días. Si tuviera que apostar cuál está más sano, elegiría el segundo. Detrás de ese tiempo están el reporting, la jerarquía, la gobernanza y la implicación real de la dirección. Por ello, mi Big Mac Index de la transformación reflejaría la distancia entre una duda y una decisión.

 

Cuando el plan deja de ser la respuesta

Todo programa largo tiene momentos en los que hay que elegir entre proteger el plan y proteger aquello para lo que se creó. En tecnología hay una dificultad adicional: el plan envejece mientras lo ejecutamos. Una arquitectura decidida al comienzo de un programa de varios años puede no ser la mejor respuesta cuando llega el momento de desplegarla.

Reducir alcance, posponer una capacidad o proteger una fecha suele ser más fácil de explicar. Y cambiar el plan para preservar la ambición exige autoridad para asumir una decisión incómoda. Eso no depende del coraje de quien decide, sino de si la organización dejó claro quién puede hacerlo. Si nadie sabe quién puede decidir, la organización tenderá hacia la opción que menos preguntas genere hoy. Y esa suele ser la que menos transforma.

Una transformación tecnológica puede durar años; las personas cambian de puesto y los partners terminan sus contratos. Si el porqué de una decisión vive solo en la cabeza de quien la tomó, la decisión se queda huérfana. Que las personas cambien de puesto es normal; que las decisiones se queden huérfanas, no debería serlo.

Los partners, como cualquier actor del programa, responden a los incentivos que diseñamos. Si medimos su éxito exclusivamente por alcance, fecha e hitos, no debería sorprendernos que optimicen precisamente esas variables. Si queremos proteger el resultado de negocio, los incentivos también tienen que mirar hacia allí.

Tomamos decisiones de arquitectura, datos y plataforma que pueden condicionar una compañía durante una década, con equipos y partners cuyo horizonte puede terminar mucho antes. Por eso la propiedad de las decisiones debe ser explícita: quién tiene autoridad, con qué criterio puede apartarse del plan y cómo se transfiere el contexto cuando cambia la persona.

En ese diseño, el sponsor cumple una función difícil de delegar: conseguir que las dudas importantes lleguen a alguien con autoridad mientras aún existe margen para actuar. Una PMO puede ordenar la información, pero no puede sustituir esa autoridad.

La escala cambia la forma, no la naturaleza del problema. En una gran corporación, esa distancia puede estar hecha de comités y jerarquías. En una empresa pequeña puede caber en una sala y ser igual de difícil de recorrer.

Ninguna de estas cosas es tecnología y, sin embargo, pueden determinar el resultado de una transformación tecnológica tanto como muchas decisiones sobre arquitectura, plataforma o proveedor.

 

Lo que se vende y lo que se transforma

Una transformación no sobrevive por elegir la plataforma correcta o al integrador de más prestigio. Sobrevive cuando la organización hace visibles las dudas, toma decisiones incómodas a tiempo y las sostiene más allá de las personas que ocupan los puestos.

La transformación no se decide en el board. Se decide en la distancia entre una duda y una decisión, en la sala donde alguien elige entre lo seguro y lo real, y sabe que tiene permiso para elegir lo segundo. Todo lo demás debería servir para acortar esa distancia.