Entre la estrategia y su ejecución hay una grieta. La arquitectura de negocios existe para encontrarla primero.
Hay una escena que se repite tanto que ya la reconocemos apenas empieza a contarse. Los dueños, la mesa chica o en ocasiones el directorio, aprueban la estrategia o la dirección para el próximo año o dos. Pasan 9 meses largos.
La transformación está atrasada 5 de esos 9 meses, el modelo operativo no alcanza para sostener ni la mitad de lo prometido, los equipos siguen trabajando cada uno por su lado, y en las "reuniones de equipo" o importantes, nadie pregunta cómo llegamos hasta acá sin verlo venir.
Casi siempre, alguien sí lo vio. Lo que faltó fue que fuera parte del trabajo de alguien decirlo en voz alta.
En Parmonia Consultores nos encontramos con esta escena una y otra vez, en industrias y países distintos, y la mayoría de las veces comparten la misma raíz: la arquitectura de negocio, la disciplina que existe justamente para prevenir esto, termina relegada al lugar equivocado. La ubican bajo TI. La reducen a una función de documentación. La confunden con tecnología o directamente con arquitectura empresarial. De esa manera, le piden que diagrame decisiones que ya fueron tomadas (decisiones que, la mayoría de las veces, nunca llegaron a diseñarse en serio). Para cuando el equipo de arquitectura de negocio entra en la conversación, si es que llega a entrar, la estrategia ya está firmada. Lo que le queda por hacer es registrar el choque después de ocurrido, como un checklist al cierre de la transformación.
Pero no es para eso que existe. Bien entendida, la arquitectura de negocio es la disciplina que traza una línea clara y verificable entre lo que el liderazgo dice que quiere y lo que la organización puede efectivamente entregar; y es esa línea la que permite detectar la ruptura antes de que se convierta en un trimestre perdido. Es uno de los pilares que sostienen la Arquitectura Empresarial en su conjunto, no un reemplazo, y mucho menos una subfunción de TI.
¿Dónde se rompe esa línea en la práctica? Acompáñanos por las capas donde solemos encontrar la grieta.
Todo empieza cuando la estrategia o dirección declara una ambición. En algún punto entre esa ambición y la estructura de la organización, alguien tiene que hacer una pregunta incómoda: ¿qué capacidades necesitamos que todavía no tenemos? También con la misma frecuencia, ¿cuáles de las que ya tenemos necesitan cambiar, en lugar de simplemente reemplazarse? Esas preguntas rara vez se hacen con la claridad que merecen. Cuando no se hace, la ambición sigue viva en el papel mucho después de que el modelo operativo dejó de poder sostenerla.
Si esa brecha de capacidades pasa desapercibida, la siguiente grieta aparece en la cadena de valor, el lugar donde "lo que somos capaces de hacer" debería convertirse en "cómo fluye realmente el trabajo, de punta a punta." Ahí es donde las estrategias que sonaban impecables en el directorio, mesa chica o dueños empiezan a exigir una coordinación que simplemente no existe entre las áreas. Nadie es dueño del traspaso ni de la transición, porque nadie se sentó a mapearlo.
Si también esa grieta pasa inadvertida, se hace visible una capa más abajo, en la jerarquía de procesos (de L1 a L5, estén formalizados o no), donde la cadena de valor tendría que traducirse en pasos concretos y ejecutables. Esta suele ser la primera capa donde alguien nota que algo no cierra, porque es la más cercana al trabajo del día a día. El problema es que, para cuando se nota ahí, ya sale caro corregirlo; y la respuesta instintiva en estos tiempos donde la tecnología evoluciona cada minuto casi siempre es automatizar, empujando la solución hacia abajo en la cadena antes de preguntarse si el proceso que se quiere automatizar realmente existe o qué capacidad se supone que lo sostiene.
Debajo de todas estas capas está la taxonomía: el lenguaje compartido que les da nombre a capacidades, procesos y cadenas de valor. Cuando esa taxonomía es inconsistente, las capas de arriba dejan de poder compararse entre sí, y la grieta queda oculta indefinidamente (contada de una forma distinta por cada área que reporta sobre ella). El mismo proceso se termina construyendo dos o más veces, con nombres distintos. Un playbook se trata como si fuera un workflow. Una iniciativa de transformación termina etiquetada como un paso de un proceso en un reporte a nivel de directorio.
No se trata de memorizar esta cadena de capas. Se trata de entender que el verdadero valor de quien hace arquitectura de negocio está en saber, exactamente, qué capa interrogar primero cuando una estrategia empieza a tambalear y en animarse a hacer ahí la pregunta incómoda, antes de que ese tambaleo se convierta en un incumplimiento que otra persona tenga que salir a explicar y defender.
Esto no es una función de TI. Es la diferencia entre una estrategia que sobrevive al contacto con la ejecución y una que no.
Comentarios