Niveles de cambio en una transformación según la alta dirección

0

Cuando se plantea un cambio cultural y organizacional importante dentro de TI es muy importante contar con la colaboración de todos los implicados. Y la mejor manera de contar con esta colaboración es que crean en el cambio. Si no creen en el cambio, será muy difícil aplicarlo. Pero quizás hay un implicado cuya colaboración es la más importante de todas: el CEO. Un cambio en TI, casi siempre es un cambio de toda la empresa, ya que de una manera u otra, estará afectada. Así, la implicación del CEO será básica en el cambio. Dependiendo de la implicación que presente el CEO, el cambio tendrá un nivel u otro, y los retos a los que nos enfrentaremos serán diferentes.

El cambio que se plantea es un cambio importante. Ejemplos de este tipo de cambios son:

  • Transformación digital
  • Implantación de cultura Agile
  • Implantación de ITIL
  • Creación de una PMO
  • Cambio de estructura organizacional dentro de TI (Por ejemplo de funciones por tecnologías a funciones por producto).

Así os presento varios niveles, y los retos principales que veo. Hablaré del CEO, pero me refiero a la más alta dirección de la empresa. Puede ser el consejo de administración, el director general, o la figura de mayor poder ejecutivo en la empresa u organización. Así que donde pone CEO, podéis poner cualquier rol que se adapte a vuestro caso.

Nivel 0: Contrario al cambio

En este nivel el CEO es contrario a que se produzca el cambio, y abiertamente así lo declara. No se puede ir contracorriente con el CEO, es muy desaconsejable. En este escenario es mejor no comenzar el cambio.

Si aún así se desea iniciar el cambio (que repito, desaconsejo hacerlo) el camino debe ser el del subterfugio:

  • Cambio muy lento
  • Sin publicidad
  • Basado en hechos consumados: se empieza a hacer algo y para cuando se descubre ya es un hecho consumado.

Resumiendo: Jugar sucio. No recomendado. Mejor renunciar.

Nivel 1: Desconocedor del cambio

El CEO no conoce el cambio. No opina, no lo entiende, no le interesa o nadie se lo ha contado. En este escenario la iniciativa nace de TI, y no cuenta con el CEO. Mi primera recomendación sería intentar explicar el cambio, o como mínimo conseguir la aprobación del cambio por parte del CEO. Pero si está inaccesible, no se podrá conseguir.

Si seguimos adelante habrá que considerar varias cosas:

  • El cambio puede hacerse, pero el coste del cambio debe ser mínimo. Nadie fuera de TI entenderá ningún coste asociado. Así que el cambio debe ser muy gradual con coste muy diluido y que apenas afecte al resto de unidades de negocio.
  • El cambio será entonces lento.
  • Debe publicitarse, pero no desde el punto de vista de intenciones (el CEO no lo ha aprobado), sino de hechos. Así, en este escenario los quick-wins serán claves. Hay que ganar aliados y así poder conseguir la aprobación del CEO.
  • No le pongamos nombres a ese cambio, hasta que se tenga la aprobación del CEO y enfoquémoslo como una mejora continua del área de TI.

Nivel 2: Aprueba el cambio que le piden, pero no lo entiende

Este es quizás el nivel más común. Al CEO se le ha “vendido” el cambio desde TI. El CEO ha “comprado” la idea, pero no la entiende. Entiende que tendrá beneficios, pero no sabe cuales son (o no los comparte). Un caso particular de esto es cuando el CEO pide un resultado y desde TI se le dice que para conseguir ese resultado es necesario el cambio. Por ejemplo:

El CEO de una empresa recibe informes de las áreas de negocio que TI llega siempre tarde a las entregas de los desarrollos. Además el resultado no es lo que negocio necesita. Y cuando se piden pequeñas mejoras, tardan un montón en hacerse. El CEO convoca al CIO y le pide que se focalice en esos puntos y los mejore. El CIO le dice que eso se puede arreglar con un equipo de desarrollo Agile, en vez de la metodología clásica. El CEO aprueba el cambio agile.

Este escenario difiere del anterior en que el cambio podrá tener un coste asociado, pero tampoco podrá ser muy elevado. Si el CEO no lo entiende no aprobará grandes inversiones o cambios disruptivos. Será algo comedido:

  • Existirá una inversión pero será reducida. No conviene intentar aumentarla, sin que haya beneficios.
  • Conseguir que el CEO “entienda” y “crea” en el cambio debe ser una prioridad. Así que los quick-wins son básicos.
  • Es buena estrategia el correlar las inversiones con ganancias no propias del cambio. Por ejemplo: Podemos implantar una cultura de QA. Aquí podemos indicar que el coste de QA es tal, o “diluirlo” en los distintos proyectos. Y si nos creemos lo de QA, quedará bien explicado, porque el sobrecoste de desarrollo, implicará una bajada de mantenimiento posterior. A lo que me refiero es que en un presupuesto o en un plan de inversiones no debe aparecer algo como: “Proyecto A: 100.000 €, QA: 30.000 €” sino “Proyecto A: 130.000 €”.
  • Debe publicitarse el cambio, con los quick-wins, pero también con intenciones. Eso sí, en las intenciones hay que dejar claro la filosofía de “gradual”, “bajo coste”, etc.

En este escenario, por resumir, tenemos aprobación, pero no alineación, del CEO. Así que hay que intentar “no asustar” al CEO con costes desorbitados (por grandes que luego sean los beneficios).

Nivel 3: El cambio viene del CEO, pero no lo entiende

Un caso muy curioso, pero que también he visto. El CEO va a una feria, o a un congreso. Allí le cuentan cuatro historias, se las cree y pide a TI el cambio. Pero realmente ese CEO no acaba de entender lo que pide. Aún así es un escenario bueno, siempre que el cambio lo veamos positivo. Es mucho mejor que te pidan lo que quieres, a que te den lo que pides.

En este escenario, el proyecto de cambio estará “patrocinado” por el CEO. Aquí hay muchas ventajas con respecto al nivel anterior:

  • Se podrán contratar servicios de consultores o coaches externos.
  • La inversión puede ser más elevada (pero con promesas que suelen salir en presupustos de ahorros o ganancias posteriores).

Por lo tanto mis consejos en este escenario serían:

  • Declarar la inversión. Pedir colaboración de otras áreas abiertamente: “Lo ha pedido el CEO”.
  • Informar al CEO de los avances y mejoras, y dejarle que pueda “ponerse la medalla” de ese cambio.
  • Educar / Explicar el cambio a cada oportunidad al CEO, para que crea en él y pasemos al siguiente nivel.

Nivel 4: El cambio está apoyado por el CEO

Este escenario es el mejor de todos. El CEO entiende de qué va al cambio, lo apoya y cree en él. Aquí la inversión puede ser muy elevada. Se pueden asumir parones o problemas iniciales. Y será mucho más fácil conseguir la colaboración de otras áreas.

Así mi consejo será considerar a ese CEO como el líder del cambio, y dejarle ese protagonismo. Esto nos dará mucha fuerza.

Y aquí deberemos aplicar el cambio de la mejor manera que nos parezca, sin pensar en si eso asustará al CEO o no:

  • Podremos proponer costes importantes, siempre que se justifiquen con ingresos o ahorros futuros. El CEO deberá aprobarlos. Pero sin miedo a pedirlos si creemos en ellos.
  • Transparencia total del proceso, a toda la organización.

Conclusiones

El nivel de implicación y validación que nos de el CEO es básico, mucho más importante de lo que pueda parecer. Por ejemplo, cualquier ISO (9.001, 27.001) nos exigirá un nivel 2 como mínimo (la famosa declaración de dirección, escrita y firmada), para pasar la auditoría. Y he visto a auditores de 27.001 preguntar a la dirección acerca del compromiso real, si entienden de que va y poner una no conformidad a la auditoría porque la dirección no sabía explicarlo.

Otro ejemplo sería en una implantación Scrum. Si el CEO no está alineado, difícilmente tendremos Product Owners implicados en el proceso o el cambio de mentalidad en la empresa con respecto a los plazos.

Es un buen ejercicio intentar contar con la validación o apoyo de la alta dirección. Pero no siempre será un apoyo pleno. ¿en qué nivel de apoyo estamos? Conviene preguntárselo y adaptarse según el nivel que tengamos.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios