¿Cómo anticiparse a una futura crisis?

Son ya muchos los años en los que se ha hablado de transformación digital. Parece, por lo tanto, un buen momento para recapitular, para pensar en qué modo ha matizado a las compañías este movimiento que se ha visto totalmente revolucionado por el COVID. De hecho, me atrevería a decir que la digitalización es un fenómeno que venía avisándonos de la necesidad de estar preparados para una disrupción en nuestro negocio, o en nuestro sector, pero nadie imaginaba que lo que llegaba era una disrupción mundial como la que ha supuesto la pandemia.

El COVID nos ha llevado a un parón radical en la mayoría de los sectores. Aunque, por el otro lado, ha habido empresas (o más concretamente áreas en empresas) que se han visto completamente inundadas de solicitudes de servicio. Estas han sido las áreas de distribución de alimentos y productos esenciales, así como aquellas que entregaban servicios de comunicación o entretenimiento (por poner algunos ejemplos). Las compañías más digitales, más adaptables, más eficaces, son las que han escalado en base a esta descomunal demanda sin que su servicio se viera afectado. Otras más tradicionales en cuanto a su tecnología y también en cuanto a su modelo operativo han sufrido durante este escalado inédito, al llegar incluso a no poder dar servicio por sufrir un bloqueo absoluto.

Ahora, pasados unos meses (aunque el problema sigue vigente), puede ser una buena ocasión para analizar cómo una organización IT, en base a los dictados de la digitalización, puede estar a la altura de una eventual nueva crisis. Para ello, a continuación expondremos a modo de resumen cómo, según el credo de la digitalización, debe una empresa estructurarse para así equilibrar, por un lado, las exigencias de agilidad a la que nos somete el entorno VUCA y, por el otro, las necesidades de control, eficiencia y homogeneización que tiene cualquier compañía de cierto tamaño.

Equilibrio entre agilidad y control

A grandes rasgos, es bien sabido que una estructura jerárquica grande, en la que la toma de decisiones está muy centralizada, es por definición una organización poco ágil. Por otro lado, las empresas que se han organizado claramente por unidad de negocio para lograr estructuras más pequeñas y donde se ha acercado la toma de decisiones a la capa operativa, han logrado agilidad a cambio de romper la homogeneidad corporativa. Entonces cabe preguntarse dónde está el equilibrio entre agilidad y control.

Dentro de cada una de esas unidades (pertenecientes a empresas que han optado por la verticalización en base a líneas de negocio) parece más fácil hacer llegar la estrategia a cada rincón. Pero no seamos ingenuos. Es necesario establecer unos mecanismos claros de comunicación que garanticen que la estrategia es canalizada desde la capa ejecutiva a la operativa. Pero la estrategia no puede ser inamovible, todo lo contrario, los ejecutivos deben tomar el pulso a la realidad (estableciendo el camino contrario esta vez desde la capa operativa hacia la ejecutiva) para así matizar la estrategia según los embates del mercado.

La estrategia es una constante en la que apostar. Desde la capa ejecutiva se persigue mover una serie de KPIs, designando una partida presupuestaria que más tarde se traducirá en acciones de negocio y en adaptaciones tecnológicas (nuevos productos digitales, nuevas funcionalidades, etc). Se espera un tiempo para recoger los resultados. Si se ha logrado mover los KPIs la apuesta habrá sido un éxito. Pero no siempre es así, en ocasiones serán necesarios ajustes a esa estrategia que, de nuevo, pueden implicar inversión. Y vuelta a empezar. Con este enfoque los tradicionalmente llamados proyectos se convierten en apuestas guiadas por la estrategia de negocio e, insisto, se hace imprescindible la comunicación fluída de la estrategia y el feedback del trabajo en campo.

Continuando con el análisis del modelo operativo de una IT digital, nos paramos ahora en la capa operativa. Esta estará más focalizada en la entrega de valor, si se organiza por equipos de producto/capacidad de negocio, en lugar del enfoque tradicional basado en departamentos. No olvidemos que los departamentos con una función concreta (arquitectura, infraestructura, desarrollo, etc) tienen objetivos propios y que la experiencia nos dice que estos objetivos muchas veces se ponderan sobre los del mismísimo negocio. Verticalizar los equipos permite alinear sus objetivos con los del producto/capacidad de negocio que soportan. Dichos objetivos serán los hitos parciales que estipula la estrategia corporativa mediante la canalización antes mencionada.

¿Qué necesitamos de nuestros equipos?

Tendríamos (con todo lo anterior) una organización capaz de trasladar la estrategia de negocio a los equipos de producto, equipos muy focalizados, capaces de tomar decisiones sobre su área de influencia, cercanos a la entrega de valor y ágiles, reaccionando ante eventualidades del entorno. Es necesario ahora garantizar que estos equipos con tanto empoderamiento, no se bifurquen demasiado y, que por el contrario, mantengan unos niveles de eficiencia acordes con el contexto, que implementen los esperados controles de seguridad y que conozcan y utilicen unos activos técnicos que, al eliminarles vicisitudes tecnológicas, les permitan estar focalizados en la búsqueda del valor de negocio.

En esta labor de homogeneización, de garantizar políticas de calidad y seguridad, está la capa de arquitectura, un gremio dentro de la empresa organizado como una Comunidad de Prácticas (CdP) que forma parte activa en los desarrollos de los productos, pero que tiene ese rol transversal de garante de las políticas. Para ello, para garantizar las mejores prácticas, y la implementación de las políticas estipuladas, ha de mantener una actitud contraria a la del tradicional departamento de arquitectura.

Ahora, es necesario convertir las políticas en soluciones (Policy as Solution): cuando en esa CdP se acuerda necesaria una política, inmediatamente esta se tiene que soportar mediante un activo técnico que facilite su implantación por parte de los equipos de producto. Además, empleando los mecanismos de comunicación propios de cualquier CdP se ha de lograr que todos los equipos estén al tanto de las políticas y los correspondientes activos/soluciones que facilitan su aplicación.

Todas estas soluciones y activos, que al final simplifican que las directrices de seguridad y calidad sean aplicadas por los equipos de producto, deben estar recogidas en un catálogo, para que así sea más fácil su localización y su gestión. Como ya estarás sospechando estos activos deben tener detrás equipos de producto que los mantengan, actualicen y soporten las eventualidades que puedan sufrir sus usuarios (los equipos de producto) y quién mejor para ello que el equipo de arquitectura y seguridad.

¿Cuáles son nuestras armas?

Hasta ahora hemos hablado de productos de negocio y de activos técnicos (ambos con equipos detrás que los evolucionan y mantienen). Como bien sabemos el tiempo de los equipos es finito y muchas veces la demanda puede superar la capacidad de desarrollo de estos equipos. Un modelo que permite lubricar la evolución de la tecnología y reducir las esperas es Inner Source. Este modelo permite que el equipo de arquitectura y seguridad sea el responsable de los activos o soluciones diseñadas para la implantación de las políticas que prescriben, pero que si otro equipo necesita un evolutivo sobre alguno de estos, pueda hacerlo para acto seguido solicitar un pull request (lo que se ha demostrado ahorra tiempo al responsable del código, lo que se traduce además en una evolución colaborativa del mismo).

Las ya mencionadas políticas de seguridad y arquitectura, según van siendo publicadas, generan una línea base de requerimientos técnicos que si no han podido ser aplicadas por cualquier eventualidad se convierten en deuda técnica. La gestión de la deuda técnica, su inventariado y su mitigación, pasa a ser una actividad de gran relevancia para garantizar las expectativas que el negocio tiene del servicio IT.

Finalmente, como guinda a este crisol de procesos, activos y personas, no podemos olvidar el tradicionalmente llamado mapa de sistemas, que en mi opinión debería ser llamado mapa de valor. Es una vista holística de la tecnología y su relación con la cadena de valor del negocio. Debe permitir conocer de un vistazo el TCO de cada sistema, sus interrelaciones, su tecnología, su estado de madurez, pero lo más importante cómo está valorado por el negocio, sus mayores inconvenientes, su aporte de valor y, finalmente, cómo es la hoja de ruta que va a garantizar su alineamiento con la estrategia de la casa.

¿Cómo prepararnos para lo que viene?

En resumen, las organizaciones verticalizadas por negocio, con una cultura de participación y proactividad, con unos mecanismos de comunicación eficaces, cuyos empleados estén organizados en base a las capacidades prestadas a los clientes, con un equipo de arquitectura y seguridad habilitador, comprometido y responsable de un catálogo de activos técnicos que faciliten la implantación de las polïticas por ellos descritas, y que además disponga de una mirada holística en forma de mapa de valor sobre su propio servicio, son organizaciones mejor preparadas para este entorno que es mucho más que cambiante.