Los tres procesos de TI vitales para los CIO

Es esencial que un CIO enfoque su atención personal en los procesos y prácticas de TI más relevantes para su actividad. En el trazado de esta estrategia, los líderes de los departamentos nunca deben patrocinar personalmente más de tres iniciativas de cambio. Superar ese número es sinónimo de perder la capacidad de concentración y, por tanto, de liderazgo.

En qué no centrarse: operaciones de TI

El candidato más obvio para organizar un programa de mejora de procesos es el conocido como marco ITIL. Pero centrarse en esto sería un error. Y, esto no significa que adoptar este marco sea un error, ya que tiene décadas de maduración detrás. Pero, el problema es que el enfoque ITIL se basa en las operaciones de TI, que solo se notan cuando algo no funciona bien y, los CIO necesitan y quieren que su presencia sea notoria cuando las cosas salen bien.

Por lo tanto, si su organización de TI necesita mejorar en la gestión de la disponibilidad, la capacidad, el rendimiento, el ciclo de vida de la infraestructura y, en especial, la gestión de cambios, asegúrese de tener a la persona adecuada a cargo de las operaciones y deje claro que se va a medir el éxito de este reto por la única métrica que importa, el índice de invisibilidad, lo que quiere decir que usted debe ser el único en darse cuenta cuando las operaciones de TI no se notan.

Como CIO debe reconocer que, si bien las operaciones de TI son sumamente importantes, no son en absoluto estratégicas, excepto si no salen bien.

Primera prioridad: la mesa de ayuda

Se conoce a la mesa de ayuda como el factor clave en la integración de éxito entre el departamento de TI con el resto de negocio de la empresa. La relación de TI con el resto de la empresa vive y muere en la mesa de ayuda. Por lo tanto, y por ejemplo, si las contrapartes comerciales le preguntan por qué TI no sabe que un sistema está inactivo hsata que llaman al servicio técnico para informarles, o si los empleados del departamento no pueden ayudar de manera instantánea a otros compañeros, preste atención personalizad a mejorar estas relaciones.

Segunda prioridad: soporte de aplicaciones

Si sus equipos de soporte de aplicaciones todavía están inmersos en metodologías en cascada empiece a convertirlos en ágiles de inmediato y supervise personalmente la estrategia de adopción ágil y su ejecución. Por otra parte, Agile es más que Scrum. Elija las variantes ágiles adecuadas para el trabajo que realmente hace TI.

La mayoría de las variantes ágiles están diseñadas para gestionar el desarrollo de aplicaciones. La mayoría de las tiendas de TI compran cuando pueden y solo construyen cuando tienen que hacerlo. Si ese es usted, ignore Scrum por completo. En su lugar, haga que sus equipos de aplicaciones adopten CRP o TDD. Asimismo, la mayoría de las variantes ágiles se centran en entregar software como producto. La gran parte de las empresas necesitan que TI colabore para lograr un cambio empresarial intencionado.

Tercera prioridad: gestión de la arquitectura de TI

Una práctica de arquitectura TI, junto con la arquitectura empresarial, corre el riesgo constante de pasar de sumar y mantener valor a convertirse en un atolladero burocrático. Aunque, este peligro no es exclusivo de la arquitectura. Cualquier empresa autorizada para revisar y criticar el trabajo creativo de otros equipos comparte el mismo riesgo.

La arquitectura de primer nivel requiere una mentalidad antiburocrática. También necesita financiación, porque los proyectos que entregan aplicaciones con características y funcionalidad satisfactorias cuestan menos que las aplicaciones con características y funcionalidades satisfactorias que se adhieren a los estándares de arquitectura.

Una función de gestión de la arquitectura de TI debe encontrar formas de lograr una arquitectura saludable y, al mismo tiempo, minimizar el uso de la aplicación como táctica principal. También debe persuadir a los líderes ejecutivos de que una buena arquitectura es una sabia decisión empresarial. Debido a estas dos preocupaciones, es difícil escapar a la conclusión de que, incluso en las mejores circunstancias, como CIO debe supervisar personalmente al equipo de arquitectura de TI.