La historia de cómo HSBC no solo digitalizó el negocio: estaban convencidos de que la simplificación y enfocarse en clientes o segmentos muy específicos eran elementos clave para el éxito de la estrategia.
Tener servicios digitales ya no es una ventaja competitiva, es un given. Todos los bancos los tienen, empresas de casi todas las industrias los están construyendo. La pregunta ya no es si tu negocio es digital, sino algo mucho más difícil de resolver: ¿cómo transforma una organización con esta escala global, con décadas de historia y capas de complejidad acumulada, sin que el proceso mismo se convierta en el problema?
Como contexto, HSBC es un banco que opera en alrededor de 64 países, sirve a 39 millones de clientes, y tiene un departamento de tecnología de 45 mil personas alrededor del mundo, de las cuales 1,500 son arquitectos. De entrada, con estos números ya te dan una idea de la magnitud del reto.
La ambición de HSBC pudiéramos resumirla en pocas palabras: volverse más simple, más rápido y más digital. El reto no está en estas palabras, radica en dónde se tiene que reflejar esa ambición para que deje de ser una aspiración y se convierta en resultado. No basta con decirlo en una junta directiva, town hall o off-site; se tiene que reflejar en el modelo operativo, en las capacidades del negocio, en los procesos que se ejecutan para atender a los clientes, en las aplicaciones o plataformas que los soportan, los datos que utilizan para tomar las decisiones y, sobre todo, en cómo los empleados hacen mejor su trabajo para darle un mejor servicio a los clientes. En esto último radica el éxito de la estrategia, que a su vez se traduce en un mejor EBITDA, valor de la acción y de la marca, etc.
Aquí es donde entra la Arquitectura Empresarial, y quiero ser claro sobre algo: no como una disciplina que documenta lo que existe, sino como la función —un músculo organizacional— que entiende, participa y traduce una ambición estratégica en decisiones concretas sobre tecnología, inversión y estructura organizacional.
“El reto para el Chief Architect tiene que ver con la estandarización e integración.”
Vale la pena detenerse en esa frase, porque ahí está el corazón de todo lo que sigue: es el pan de cada día de las empresas que estandarizan e integran de la forma adecuada.
Simplificar la estructura no es lo mismo que simplificar la operación
El primer gran movimiento de HSBC fue simplificar su estructura organizacional para acelerar la ejecución de sus prioridades estratégicas. El resultado de negocio que buscaban era: ahorro en costos, eficiencia operativa e impacto en el resultado final —bottom up—. La estrategia detrás también era muy directa: simplificación organizacional.
Pero lo que esto realmente significa para el negocio es algo más difícil de implementar: simplificar el proceso de toma de decisiones. No se trata solo de tener menos capas jerárquicas en un organigrama, se trata de que, al final del día, sea más claro quién decide qué.
Ya nos la sabemos de memoria: empoderar a los equipos para que sean más autónomos. Pero en la práctica, ¿cómo?
Y aquí es donde la influencia del arquitecto se vuelve indispensable. Porque para que la estrategia de simplificación tenga sentido, y logre conectar con la ejecución, tiene que quedar claro qué unidad de negocio es dueña de qué capacidades, qué plataformas merecen inversión —modernización—, y dónde existe duplicidad que debe eliminarse.
Este último punto merece un zoom, porque es una de las lecciones más importantes de todo el caso: las estructuras organizacionales cambian más rápido que la tecnología que las soporta. Los bancos —y en realidad cualquier empresa grande— pueden reducir capas de gestión en un organigrama sin necesariamente reducir la cantidad de procesos, value-streams, controles, aplicaciones y definiciones de datos que existen por debajo de esa estructura.
Es decir: puedes simplificar en el Power Point, pero si no tocas la arquitectura que sostiene la operación, la complejidad simplemente se queda ahí, escondida niveles más abajo.
El verdadero indicador de éxito para decir que la estrategia se está ejecutando correctamente no es que el organigrama se vea más simple. Es que esta nueva estructura efectivamente determina con claridad quién es dueño de qué plataforma y quién toma las decisiones de inversión, si de verdad se reduce la duplicidad de plataformas, y si existe un gobierno en la inversión de tecnología.
De sistemas locales a una plataforma global
El segundo movimiento estratégico fue muy distinto, pero está conectado con el primero. En lugar de mantener sistemas de comercio internacional separados para cada país, HSBC tomó la decisión de implementar una plataforma global, conectando a sus clientes corporativos a través de APIs —modelo B2B—.
Para el negocio, esto se tradujo en una mayor flexibilidad: un cliente corporativo que opera en distintos mercados no tiene que lidiar con sistemas fragmentados y desconectados entre sí; la experiencia del cliente se vuelve consistente sin importar en qué país esté operando.
Esta decisión implicó estandarizar cómo se captura, se reutiliza y se expone la información a través de distintos productos y mercados —implica una estrategia de data management como fundamento para que esto funcione bien—.
Platform Thinking no solo es una decisión de tecnología, requiere un cambio de mindset más difícil de lograr en una empresa de este tamaño; implica que distintas unidades de negocio dejen de construir soluciones aisladas en su propio contexto o urgencia, y empiecen a pensar en capacidades compartidas que sirvan a toda la empresa, con una vista global.
No es una decisión técnica. Es una decisión de negocio con implicaciones técnicas muy profundas, que van desde la selección y retención de talento.
La velocidad de la información también es una decisión
El tercer movimiento tiene que ver con algo que pudiera sonar muy operativo, pero que en realidad es estratégico: incrementar la velocidad con la que fluye la información de pagos.
Lo que esto significa para el negocio es que los clientes pueden usar datos en tiempo real para conciliar sus operaciones y planear con mayor precisión. En un entorno donde la velocidad de decisión es una ventaja competitiva, tener acceso a información actualizada al instante deja de ser un lujo y se convierte en una necesidad operativa.
Esto implica integrar los datos del back-office con los sistemas ERP. No es un problema tecnológico aislado, es un problema de Arquitectura de Información diseñado para soportar tanto la experiencia del cliente como la eficiencia operativa, a través de una estrategia de integración de datos.
“La arquitectura de información debería partir del flujo de trabajo, no de la tecnología en sí misma.” | diferenciar entre Data Products vs General Data Purpose
Es una distinción que parece poco relevante, pero que en la práctica lo puede cambiar todo. Cuando empiezas por la tecnología, terminas construyendo soluciones que no necesariamente resuelven el problema real del negocio. Pero cuando empiezas por el flujo de trabajo —cómo se mueve realmente la operación, dónde están los puntos de fricción, qué necesita el cliente en cada momento de la verdad— la tecnología se convierte en un habilitador, no en el punto de partida.
Innovar sin perder el control
El cuarto movimiento estratégico de HSBC tiene que ver con activos digitales reutilizables. Esto habilitó capacidades como distributed ledger, y permitió la entrada a la innovación en mercados de capital, mayor transparencia y resiliencia operativa y regulatoria.
Existe una diferencia enorme entre un experimento tecnológico — las famosas PoV o PoC — y una capacidad de negocio.
Un experimento puede vivir aislado, sin las implicaciones que requiere escalarlo, implementar seguridad, monitoreo, observabilidad que exige la operación real. Una capacidad, en cambio, requiere el músculo institucional para entregarse de forma segura, gobernada, controlada, y conectada con el resto del ecosistema tecnológico y modelo operativo de la empresa.
Muchas organizaciones confunden estas dos cosas. Celebran el experimento como si fuera la transformación, cuando en realidad el trabajo más difícil —y el que genera valor sostenible en el tiempo— es el que convierte ese experimento en algo que puede operar de forma segura y a la escala del negocio global.
El punto medio que los griegos ya conocían
Aquí llegamos a una de las tensiones más reales de cualquier transformación de esta magnitud, y quiero ser honesto contigo: no existe una respuesta perfecta, transformar una empresa implica arte, una habilidad que solo te la da la experiencia.
Un banco del tamaño de HSBC no se puede gestionar con un solo sistema global; siempre va a existir la necesidad de justificar excepciones, de hacer trade-offs, de dar autonomía local o regional para adaptarse a cada mercado, cada país, cada oferta específica.
La parte difícil —la que de verdad distingue a empresa que logra ejecutar su estrategia de forma correcta de una que solo persigue estandarización por estandarización— es encontrar el punto medio. O como dirían los griegos, el punto justo.
Se trata de tener modelos de datos, servicios e interfaces comunes, con responsabilidades claras, pero con espacio para una personalización controlada donde exista una razón de negocio genuina que la justifique.
Nunca es blanco o negro, es un ejercicio constante de calibración entre reutilización de plataformas y racionalización o modernización de aplicaciones, dos fuerzas que en apariencia jalan hacia direcciones opuestas, pero que bien equilibradas son las que permiten que una empresa compleja se mueva con velocidad sin perder el control. | Arquitectura de Integración
Cuando este equilibrio se ejecuta correctamente, los resultados se ven reflejados en cosas muy tangibles: reducción en el cycle-time, menos trabajo manual, mejor detección de riesgos, menor costo de soporte y hasta una posible reducción de la deuda técnica. Con el tiempo, estos cambios también los reconoce el mercado, los inversionistas observan cómo el banco ejecuta su estrategia, y esa ejecución se traduce en una percepción de una organización más simple, más eficiente y más rentable.
El reto de ver toda la organización al mismo tiempo
Quiero ahora contarte la otra mitad de esta historia, porque no basta con tener la estrategia correcta, también hay que resolver un problema mucho más fundamental y, honestamente, mucho más difícil de lo que parece: ¿cómo obtienes visibilidad real de tu propio footprint tecnológico?
Para HSBC, esto significaba mapear la tecnología frente a sus servicios y capacidades de negocio, en un entorno con aplicaciones distribuidas en distintas regiones y distintas unidades de negocio —Wealth and Personal Banking, Commercial Banking, Global Banking & Markets—, cada una con su propia forma de operar. El reto es enorme.
Los equipos federados de una organización de este tamaño desarrollan sus propias taxonomías, modelos y sus propias formas de colaborar y de comunicarse con el negocio. Cada equipo termina hablando, un idioma distinto.
Para lograr resolverlo HSBC evaluó las fuentes de datos disponibles para determinar cuáles se podían confiar. Identifico los inventarios y repositorios de activos existentes —muchas veces dispersos entre hojas de cálculo y herramientas como ServiceNow—. Revisaron si existía algún modelo o taxonomía que se pudiera aprovechar.
Tuvieron que entender la nueva estructura organizacional, examinar como estaban construidas las líneas de negocio y líneas de servicios, pero sobre todo los flujos de valor (value-streams).
A partir de este entendimiento desarrollaron una taxonomía compartida con todas las unidades de negocio, y se construyó un nuevo modelo de capacidades para toda la organización. Este paso, en particular, requiere discusiones extensas para resolver matices, diferentes perspectivas de los lideres de negocio y llegar a consenso. No es un ejercicio técnico que un equipo de arquitectura o de transformación pueda resolver en aislamiento; es un proceso profundamente político y organizacional.
El primer entregable de todo este trabajo fue un reporte capaz de conectar activos tecnológicos que normalmente viven desconectados entre sí: flujos de valor, programas estratégicos, unidades organizacionales, aplicaciones/plataformas, capacidades y procesos de negocio. El resultado fue un landscape tecnológico que demuestra qué aplicaciones son estratégicas, cuál es su costo total de propiedad (TCO), y qué impacto tienen en los distintos proyectos. Todo esto con la intención de habilitar decisiones informadas y hojas de ruta basadas en el ciclo de vida de cada aplicación, su categorización estratégica y los paquetes de trabajo que permiten a los distintos stakeholders tomar mejores decisiones.
La adopción lo es todo
Si me preguntas cuál fue el factor que realmente determinó si todo este esfuerzo se tradujo en valor real, no dudaría en responderte: la adopción.
“La adopción lo es todo.”
De nada sirve construir el mapa más completo y sofisticado de tu landscape tecnológico si nadie en el nivel directivo entiende por qué debería importarle o como usarlo, por eso la capacitación fue clave para lograr la adopción a nivel C-Level. Los stakeholders necesitaban entender el valor de tener acceso a este tipo de visibilidad para poder tomar decisiones informadas, basadas en datos.
Esa visibilidad, una vez adoptada, habilitas conversaciones muy estratégicas: sobre la inversión en nuevas plataformas, cuales se deben modernizar o en caso eliminar, cuánto cuesta operar la tecnología para una unidad de negocio, cuáles son los riesgos tecnológicos, como será la evolución de la tecnología considerando las tecnologías emergentes.
Y aquí hay una última lección que, como considero de las más importantes de todo este caso: la calidad del dato es la que determina si todo este esfuerzo genera valor real o se queda en un ejercicio consultivo. Es fundamental poder identificar información incorrecta y tomar acciones correctivas a tiempo, porque un mapa construido sobre datos poco confiables termina generando decisiones igual de poco confiables dañando al negocio en el largo plazo.
Lo que esto significa si tú eres quien estas metidos en programas de transformación
Si llegaste hasta aquí, probablemente ya identificaste el hilo conductor de toda esta historia. HSBC no transformó su negocio comprando la tecnología más nueva del mercado, transformó su negocio porque fue capaz de conectar cada decisión de tecnología —cómo se estructura la organización, cómo se construyen las plataformas, cómo fluye la información, cómo se gobierna la innovación— con un resultado y beneficios esperado de negocio medible.
Ese es, en el fondo, el verdadero mandato de la Arquitectura Empresarial. No documentar lo existente, no producir diagramas para el archivo. Sino traducir la ambición estratégica de un CEO en decisiones concretas sobre estructura, plataformas, datos y gobierno de tecnología, de forma que la complejidad de una organización global deje de ser un obstáculo y se convierta en la base sobre la cual se construye la siguiente etapa de crecimiento.
La pregunta que te dejo, si estás al frente de una organización tan compleja como HSBC, no es si necesitas transformarte digitalmente. Esa ya la respondiste hace tiempo, la pregunta es si tu arquitectura empresarial —tu estructura, tus plataformas, tus flujos de valor, tus aplicaciones, tus datos, las interfaces, el gobierno— está listo para sostener esa transformación sin que se convierta en sí mismo, en el siguiente problema que tengas que resolver tu o lo más probable es que sea otra persona.