Implementación de la hoja de ruta

Cuando haya establecido la hoja de ruta, debe implementarla. Hemos descubierto que aquí es donde los clientes se enfrentan al siguiente desafío: han dedicado tiempo a pensar y ahora tienen que ponerse manos a la obra. Le recomendamos que siga estos pasos para conectar la estrategia con la implementación:

Decisión del punto de partida y cómo empezar

Parece fácil, pero, con tanto por hacer, encontrar un punto de partida suele ser una cuestión difícil y debatida. Las organizaciones que se trasladan a la nube tienen mucho en qué centrarse, y la iniciativa puede resultar abrumadora si no se pone en contexto. Con el paso de los años, las tendencias de los clientes han evolucionado, pero un punto de partida coherente es el liderazgo transformador. Impulsar las directrices y la estrategia desde arriba hacia abajo y crear la declaración de objetivos, los principios y el comunicado de prensa con las preguntas frecuentes permiten a la administración intermedia y a las personas tomar decisiones de forma autónoma, aportar claridad e impulsar el valor empresarial a partir de la transformación de la nube. Si no ha hecho este ejercicio ni nada similar, se lo recomendamos como primera tarea.

Durante este ejercicio, debe reconocer que, a diferencia de otras transformaciones tecnológicas, la transformación de la nube acerca la tecnología a la empresa. La tecnología es una palanca que utilizan las empresas para alcanzar objetivos más amplios, ya que permite la agilidad, la estabilidad, la optimización de costos y resultados similares. Debe planificar esta transformación con la tecnología y la empresa, con la estrategia de la organización en un plazo de 3 a 5 años como punto de partida, la identificación de los objetivos a lo largo del camino y sin miedo a cambiarlos cuando sea necesario.

Organización para tener éxito

La estructura de la organización para alcanzar los objetivos de transformación, adopción y migración a la nube cambiará a medida que la organización madure. Comprenderlo, prepararse para ello y tener la intención de hacerlo es clave para garantizar el éxito.

Por lo general, al principio del proceso, los equipos más grandes trabajan en el entorno en las instalaciones. A continuación, a medida que crece la adopción de la nube, estos equipos migran para crear, desarrollar, operar y optimizar la plataforma en la nube, y su organización debe adaptarse a las nuevas formas de trabajar en cada una de estas etapas. Hemos observado que un cambio difícil, pero importante, se produce cuando una organización traslada entre el 5 % y el 10 % de sus cargas de trabajo a la nube (cuando se pasa de la fase de lanzamiento a la fase de escala). En este punto, una organización utiliza equipos en las instalaciones para administrar los recursos en la nube porque la migración no es lo suficientemente grande como para merecer cambios a tiempo completo, por lo que estos equipos tienen que encontrar un equilibrio entre las responsabilidades actuales y las nuevas. Al mismo tiempo, los equipos en las instalaciones a los que ahora se les pide que operen servicios en la nube requieren nuevas habilidades, lo que implica una curva de aprendizaje pronunciada.

Para entender su organización y desarrollar un plan que permita estos cambios, le recomendamos que analice la topología de los equipos de la organización de TI. Usamos este método con los clientes para comprender la organización y la interconexión de las funciones dentro de una organización de TI, que suele ser diferente de las estructuras organizativas, y luego utilizamos el marco del COM de AWS como guía sobre cómo organizarnos para cumplir con las etapas e hitos de la transformación. Este ejercicio se basa en cualquier cambio en la estructura organizativa que pueda ser necesario.

Las topologías que hemos utilizado con los clientes incluyen modelos descentralizados, centralizados y federados. Amplían las representaciones 2 por 2 del modelo operativo que se incluyen en el pilar de excelencia operativa del Marco de AWS Well-Architected.

Descentralizado

Las grandes empresas globales que operan en diferentes regiones geográficas o segmentos industriales suelen utilizar el modelo descentralizado, como se ilustra en el siguiente diagrama. En estas empresas, las unidades de negocio individuales tienen sus propias disposiciones de TI que pueden superponerse a las de otras regiones o unidades de negocio. Sin embargo, suele entenderse y aceptarse como una forma de proporcionar autonomía y especialización dentro de la región.

El uso del enfoque descentralizado significa que cada región o unidad de negocio tiene su propio modelo operativo en la nube que se adapta a las necesidades de la región o unidad de negocio.

Centralizado

Una función de TI centralizada es el modelo que vemos con más frecuencia. Cuando se implementa este modelo, los clientes buscan mantener la misma topología al establecer el modelo operativo en la nube. Esto se explica en el siguiente diagrama.

En este modelo, el equipo central proporciona una plataforma seleccionada que pueden utilizar los equipos de cargas de trabajo que tienen sus propios modelos operativos en la nube. Con este enfoque, los equipos de cargas de trabajo pueden centrarse en el valor que proporcionan a sus clientes finales sin tener que preocuparse por los servicios, las operaciones ni la seguridad de la plataforma que utilizan. Este modelo funciona bien para las empresas más pequeñas. Sin embargo, en las grandes organizaciones globales, el número de equipos de carga de trabajo puede ser de cientos o miles. Para administrar a esta escala sin perder los beneficios de una plataforma central, las organizaciones suelen hacer la transición al modelo federado, como se describe en la siguiente sección.

Federado

Muchas organizaciones adoptan el modelo de TI federado porque proporciona una función central responsable de la plataforma en la nube, pero permite varios modelos operativos a nivel de carga de trabajo. Esto significa que el equipo central puede centrarse en proporcionar la mejor plataforma posible para la organización sin la limitación de trabajar con el mínimo común denominador. En el diagrama siguiente se ilustra el modelo federado.

En las grandes organizaciones, el modelo federado proporciona la autonomía que requieren los equipos de ingeniería y, al mismo tiempo, garantiza que el equipo central proporcione la plataforma y el trabajo pesado indiferenciado común para todas las cargas de trabajo. En este modelo, el equipo central debe trabajar de la misma manera centrada en el producto que los equipos de ingeniería, pero su producto es la plataforma.

Cambios en la topología para adaptarla al proceso

La topología que elija dependerá del tamaño de la empresa, pero también se ajustará a la etapa del traspaso a la nube. La organización de los departamentos o equipos no es estática, sino que cambia con cada etapa de la adopción de la nube. Esto significa que puede diseñar, analizar y ampliar diferentes topologías a medida que cambia el entorno. Algunos ejemplos de factores influyentes son los siguientes:

Creación de mecanismos para impulsar el cambio

En Amazon, un mecanismo se define de la siguiente manera: proceso completo que convierte las entradas en salidas y se ensambla a partir de palancas organizativas. Utiliza datos y comentarios para respaldar el proceso y garantizar que se obtengan los resultados. Dado que cada organización es diferente, cada modelo operativo en la nube lo es cada vez más, pero todas necesitan un mecanismo para impulsar el cambio.

Le recomendamos que dedique tiempo a comprender y desarrollar los mecanismos que se adapten a los cambios necesarios para implementar el modelo operativo en la nube. Un enfoque popular es adoptar los principios ágiles. Los mecanismos ágiles eliminan las barreras organizativas y basadas en procesos entre los equipos aislados y crean bucles de comentarios para garantizar que la organización dedique tiempo a innovar en las actividades más impactantes que generarán el mayor valor empresarial.

Desarrollo de la madurez de forma gradual

La madurez en el contexto de un modelo operativo en la nube se refiere a la distancia a la que están sus capacidades de las formas de trabajar que priorizan la nube. Por ejemplo, ¿cuánta autonomía tienen los procesos y cuánta participación humana se necesita para administrar el negocio como siempre (dirigir la empresa) en comparación con la innovación (cambiar la empresa)? Si las actividades se inclinan más hacia lo primero, la madurez (en la nube) es baja; sin embargo, si se asemejan a lo segundo, la madurez es mayor. Estar en un lugar bajo en la escala de madurez no es negativo, sino un reflejo del punto en el que se encuentra en el camino. El objetivo es entender dónde se encuentra y hacia dónde necesita llegar. Cuando trabajamos con los clientes de AWS, utilizamos una escala de madurez dentro del marco del COM de AWS para indicarles los pasos que deben seguir a lo largo del proceso.

Recomendamos utilizar un mecanismo para aumentar gradualmente la madurez de todas las capacidades del marco de COM de AWS. Un ejemplo de cómo hemos trabajado con los clientes de esta manera es convertir las revisiones de madurez y la priorización (entradas) en un aumento de la madurez (resultados) y, a continuación, organizar eventos basados en la experiencia, como días de juego (bucles de comentarios) para verificar los resultados y ajustarlos según sea necesario. Al establecer estos mecanismos junto con los clientes, hemos descubierto que, cuando se desarrolla esta fortaleza organizativa, no solo permite alcanzar hitos inmediatos, sino que también permite una mejora gradual que dura más allá de las fases iniciales del proceso.

Prestar atención a desarrollar las capacidades de la organización y a incorporar gradualmente los cambios necesarios en capacidades específicas, en momentos específicos de la hoja de ruta, vincula la estrategia con la implementación. También lo ayuda a aprovechar las economías de escala que se obtienen al aprovechar los logros anteriores.