Los procesos son importantes, pero algunos son más que otros. Y ahí es donde debe poner su talento en juego, como líder de TI.

El principio núm. 7 del Manifiesto Keep the Joint Running señala que “antes de poder ser estratégico, hay que ser competente”.

Los procesos y prácticas de TI son la forma en que se realiza el trabajo de TI. Es donde ocurre la competencia, o su ausencia.

Pero, ¿cuáles deberían elegir los CIO?

Operaciones de TI: en qué no centrarse

El candidato más obvio para organizar su programa de mejora de procesos es el conocido marco ITIL. Pero eso sería un error.

No es que adoptar el marco ITIL sea un error. Es un marco perfectamente fino con décadas de maduración detrás. Es que el enfoque de ITIL está en las operaciones de TI. Y las operaciones de TI sólo se notan cuando algo sale mal. Como CIO, usted quiere que le noten cuando algo sale bien.

Por lo tanto, si su organización de TI necesita mejorar en la gestión de la disponibilidad, la gestión de la capacidad, la gestión del rendimiento, la gestión del ciclo de vida de la infraestructura, la administración de sistemas y, en especial, la gestión de cambios, asegúrese de tener a la persona adecuada a cargo de las operaciones de TI y deje en claro que va a medir su éxito por la única métrica de operaciones de TI 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 que, como se señaló, si no se hace bien, no puede ser estratégico.

Delegarlo y asegurarse de que el gerente al que lo delegue tenga todas las herramientas y el apoyo que necesita.

Prioridad de proceso n° 1: la Mesa de Ayuda

Arreglar la Mesa de Ayuda (Help Desk) debe ser su máxima prioridad si la reputación de TI, que es toda la reputación de TI, es menos que estelar.

La Mesa de Ayuda es el hijastro pelirrojo de TI, lo cual es lamentable, porque un factor clave en la integración exitosa de TI con el resto de la empresa es la calidad de la relación empresa / TI.

La relación de TI con el resto de la empresa vive y muere en la Mesa de Ayuda. Por lo tanto, si escucha que se lo conoce como el “escritorio indefenso” o si sus contrapartes comerciales le preguntan por qué TI no sabe que un sistema está inactivo hasta que llaman al Servicio de Asistencia Técnica para informarles, o si escucha que el personal del departamento de Asistencia Técnica está cambiando historias de usuario tontas, o si, cuando alguien llama a la mesa de ayuda para algo rápido y simple y la Mesa de Ayuda les da un número de ticket en lugar de la respuesta de 10 segundos que necesitan en este momento, elija su síntoma y si la Mesa de Ayuda lo muestra , preste atención personal a la reparación de la Mesa de Ayuda.

El soporte empresarial que necesitará para que el resto de su organización de TI brille depende de ello.

Prioridad de proceso n° 2: soporte de aplicaciones

• Regla 1: si sus equipos de soporte de aplicaciones todavía están inmersos en metodologías en cascada, ¿qué está usted esperando? Empiece a convertirlos en ágiles de inmediato y supervise personalmente la estrategia de adopción ágil y su ejecución.

• Regla 2: Agile es más que Scrum. Elija las variantes ágiles adecuadas para el trabajo que realmente hace TI, no Scrum porque “eso es lo que todos están usando”.

• Regla 3: 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 sólo construyen cuando tienen que hacerlo”. Si es usted, ignore Scrum por completo. En su lugar, haga que sus equipos de aplicaciones adopten CRP (piloto de sala de conferencias) o su primo cercano, ATDD (desarrollo impulsado por pruebas de aceptación).

• Regla 4: la mayoría de las variantes ágiles se centran en entregar software como producto. La mayoría de las empresas necesitan que la TI colabore para lograr un cambio empresarial intencionado. Modifique las variantes ágiles que adopte para que esto sea lo que hagan.

Prioridad de proceso n° 3: gestión de la arquitectura de TI

Es recomendable evaluar la calidad y la excelencia de la propia arquitectura de TI en la próxima entrega de esta serie. Si es deficiente, es un síntoma de una práctica de gestión de la arquitectura de TI fallida, por supuesto.

¿Cuáles son otras señales de que su práctica de gestión de arquitectura de TI necesita ayuda?

“No podemos decir qué tan buena es nuestra arquitectura”, es un síntoma común sorprendente y deprimente. En realidad, “No sabemos lo que tenemos” no es tan inusual.

¿Qué otros aspectos necesita usted verificar? Entre otros están:

Si usted publicó y publicitó una lista corta (y no más de una docena) de principios de arquitectura que guían todo lo demás. Porque, más allá de ser breves, los principios deben estar escritos en un lenguaje sencillo y sin jerga confusa.

Si publicó y publicitó una lista de estándares que están arraigados en los principios; si se mantuvo actualizado sobre la base de una práctica bien documentada; y si está actualizado en un periodo regular, digamos trimestralmente, entonces tiene sentido.

Si estableció la gestión del ciclo de vida como práctica estándar, integrándola en la planificación y el presupuesto de TI.

Si desarrolló una estrategia de nube basada en los principios y estándares de la arquitectura, y en torno a la comprensión de que la nube es una arquitectura, no un lugar de almacenamiento y procesamiento.

Pero, aunque la arquitectura de TI esté libre de estos defectos, eso no significa que la práctica está en buenas manos.

Además, este peligro no es exclusivo de la arquitectura. Cualquier organización 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 financiamiento, porque los proyectos que ofrecen aplicaciones con características y funcionalidad satisfactorias cuestan menos que las aplicaciones con características y funcionalidad satisfactorias que se adhieren a los estándares arquitectónicos.

Como es poco probable que su patrocinador ejecutivo promedio esté dispuesto a pagar la diferencia, los proyectos que entreguen o modifiquen la funcionalidad de la aplicación necesitarán un subsidio de arquitectura para cubrir el margen.

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 inversión empresarial. Debido a estas dos preocupaciones vitales, 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.

Pero, ¿qué pasa con la seguridad de la información?

En los tiempos que corren, donde las amenazas relacionadas con las TI para las empresas están cada vez más patrocinadas por el crimen organizado y los actores estatales malintencionados, y donde el daño potencial de las intrusiones de hace mucho tiempo pasó de ser una “agravación” a una “enorme dificultad”, la seguridad de la información debe ser una de las principales prioridades de TI. Pero, al igual que en las operaciones de esta área, la eficacia de la seguridad de la información se mide mediante su propio índice de invisibilidad.

Sólo que es peor, porque para ser eficaz, la seguridad de la información tiene que ser intrusiva, por lo que cierto nivel de visibilidad desagradable acompaña al territorio.

Una cosa más: la seguridad de la información que no esté estrechamente unida a la arquitectura de TI de alta calidad será una seguridad de la información con agujeros.

Por lo tanto, incorpore la seguridad de la información a su práctica de arquitectura de TI, donde usted, como CIO, también puede vigilarla, sin que esto fragmente aún más su atención.

Abordar la innovación de TI (también conocida como “digital”)

Observe dónde están ocurriendo las oportunidades comerciales para la innovación y encontrará que la tecnología de la información es, si no el principal competidor, sin duda entre los tres primeros.

Como CIO, sus opciones aquí son hacerse cargo de la innovación de TI o adoptar la idea de agregar un director digital al equipo de liderazgo ejecutivo.

Pero eso constituiría una proclamación de insuficiencia de su parte. Además, dividiría el liderazgo de TI en dos, y el CDO se convertiría en el Capitán mientras que usted se convertiría en el Dr. No.

No hagamos eso.

En su lugar, incorpore la innovación de TI a la práctica de la arquitectura de TI. Hacerlo no sólo le da a la innovación un hogar organizacional para que no fragmente su atención, sino que también coloca la responsabilidad de la innovación en el mismo lugar que la necesidad a largo plazo de integrar las innovaciones de TI en el resto de la arquitectura de TI. Después de todo, no desea que las innovaciones de TI se conviertan en islas de automatización del futuro.

En conclusión

Para que su área de TI sea competente, usted debe emplear prácticas y procesos bien diseñados, definidos y documentados. Los CIO son responsables de todos ellos, pero en la práctica no pueden guiar personalmente una transformación de más de tres.

En la mayoría de las organizaciones de TI, los tres dominios de procesos que más necesitan el liderazgo personal de los CIO son la Mesa de Ayuda, el soporte de aplicaciones y la gestión de la arquitectura de TI. Púlalos para que brillen y la TI tendrá éxito, y tendrá un éxito visible.

Eso es sólo si las operaciones de TI también brillan, razón por la cual, paradójicamente, los CIO deberían asegurarse de delegar esa responsabilidad. Si no lo hace, no le quedará suficiente ancho de banda para pulir los tres grandes.

Bob Lewis, CIO.com