[07/09/2021] El Principio No. 7 del Keep the Joint Running Manifesto afirma que, antes de que usted pueda ser estratégico, tiene que ser competente.
Los procesos y prácticas de TI son la forma en que se realiza el trabajo de TI. Es donde la competencia, o su ausencia, ocurren.
La entrega anterior de esta serie habló sobre las duras verdades de lo que significa "mejorar” los procesos y prácticas de TI. La pregunta ahora es en cuál de ellos usted, como CIO, necesita enfocar su atención personalmente.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
La respuesta comienza con este principio básico: los gerentes nunca deben patrocinar personalmente más de tres iniciativas de cambio. Supere ese número mágico y perderá la capacidad de concentrarse y, por lo tanto, de liderar.
Pero ¿cuáles deberían elegir los CIO?
En qué no centrarse: Operaciones de TI
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 de ITIL sea un error. Es un marco perfectamente bueno, con décadas de maduración. Lo que sucede es que ITIL se enfoca en las operaciones de TI. Las operaciones de TI solo se notan cuando algo sale mal. Como CIO, usted quiere ser reconocido 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 gestión de sistemas y, en especial, la gestión del cambio, asegúrese de tener a la persona adecuada a cargo de las operaciones de TI, y deje en claro que usted 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. Aunque, como se señaló anteriormente, si no se hacen bien, usted no podrá ser estratégico.
Delegue las operaciones y asegúrese de que el gerente a cargo tenga todas las herramientas y el apoyo que necesita.
Prioridad procesal Nro. 1: La mesa de ayuda
Arreglar la mesa de ayuda debe ser su máxima prioridad si la reputación de TI -o sea, toda la reputación de TI- no alcanza la perfección.
La mesa de ayuda es la hijastra pelirroja 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 entre la empresa y TI.
La relación de TI con el resto de la empresa vive y muere en la mesa de ayuda. Entonces, si usted escucha que se le conoce como la "mesa que no ayuda”, o si sus contrapartes del negocio le preguntan por qué TI no sabe que un sistema no funciona hasta que llaman a la mesa de ayuda para informarles, o si escucha que el personal de la mesa de ayudaintercambia historias de usuarios 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 rápida que necesitan en ese momento -elija su síntoma y si la mesa de ayuda lo presenta- entonces preste especial atención 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 procesal Nro. 2: El soporte de las aplicaciones
Regla 1: Si sus equipos de soporte de aplicaciones todavía están inmersos en metodologías de cascada, ¿qué está esperando? Empiece por convertirlos en ágiles de inmediato y supervise personalmente la estrategia de adopción ágil y su ejecución.
Regla 2: La metodología ágil es más que Scrum. Elija las variantes ágiles adecuadas para el trabajo que realmente hace TI, y no Scrum solo 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 los usuarios 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 el CRP (piloto de sala de conferencias) o, su primo cercano, el 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 TI colabore para lograr un cambio empresarial intencionado. Modifique las variantes ágiles que adopte para que esto sea lo que hagan.
Prioridad procesal Nro.3: La gestión de la arquitectura de TI
Cubriremos cómo evaluar la calidad y la excelencia de la propia arquitectura de TI en la próxima entrega de esta serie. Si es deficiente, por supuesto, es un síntoma de una práctica de una mala gestión de la arquitectura de TI.
¿Cuáles son otras señales de que su gestión de la 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, el 'no sabemos lo que tenemos' no es tan inusual.
¿Qué otra cosa le falta?:
- La publicación en una lista corta -no más de una docena- de principios de arquitectura que guíen todo lo demás. Y más allá de ser breves, los principios deben estar escritos en un lenguaje sencillo y sin jerga.
- La publicación de una lista de estándares que están: arraigados en los principios; actualizados respecto a la base de una práctica bien documentada; y actualizados regularmente -trimestralmente tiene sentido.
- El establecimiento de la gestión del ciclo de vida como práctica estándar, integrándola en la planificación y el presupuesto de TI.
- El desarrollo de 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.
Eso no significa que si la arquitectura de TI no presenta estos defectos, la práctica esté en buenas manos.
La arquitectura de TI, junto con la arquitectura de la empresa -su prima ya integrada en el negocio-, siempre se encuentra en riesgo de convertirse en un atolladero burocrático cuando antes agregaba valor para la empresa y lo mantenía en el tiempo.
Este peligro no es, por cierto, 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 financiación, porque los proyectos que entregan 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 arquitectónico para cubrir la diferencia.
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 esta época, donde las amenazas relacionadas a la TI empresarial están cada vez más patrocinadas por el crimen organizado y los estados malintencionados, y donde el daño potencial de las intrusiones hace mucho tiempo pasó de "agravamiento” a "enorme”, la seguridad de la información debe ser una de las principales prioridades de TI. Pero, al igual que en las operaciones de TI, la eficacia de la seguridad de la información se mide mediante su propio índice de invisibilidad.
Solo 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 va con el territorio.
Un punto más: La seguridad de la información que no está estrechamente unida a la arquitectura de TI de alta calidad es 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')
Mire dónde están ocurriendo las oportunidades de negocio para la innovación y encontrará que, si no es la principal competidora, la tecnología de la información sin duda se encuentra entre las tres primeras.
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 Debemos hacerlo”, mientras que usted se convertiría en el "Dr. No”. Y, por lo tanto, el "CIO” se convertiría en una declaración de su plan de jubilación ("La carrera ha terminado”).
No hagamos eso.
En su lugar, incorpore también la innovación de TI a la práctica de la arquitectura de TI. Hacerlo no solo 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 deseará que las innovaciones de TI se conviertan en futuras islas de automatización.
Cómo manejar 'DIY IT'
TI hágalo usted mismo, también conocida como "TI paralela”, "TI rebelde” y "¡¡¡YA BASTA!!! ¡Me está dando migraña de TI!”, es algo que muchos CIO hacen todo lo posible por eliminar.
En esto, se parecen al rey Canuto ordenando que la marea no suba.
Y, de todos modos, la TI paralela es más una oportunidad que un problema, ya que aumenta drásticamente el ancho de banda de TI de la empresa sin aumentar su gasto en TI -o al menos su gasto visible en TI.
Los inconvenientes de la TI paralela son, en su mayor parte, evitables. Principalmente, es necesario que TI proporcione un mínimo de soporte en términos de consulta técnica para garantizar que cumpla con los estándares de la arquitectura de TI, a cambio de que los encargados de la arquitectura de TI tengan la documentación que necesitan para evitar que la TI paralela se vuelva una TI encubierta.
Esto hace que el soporte para la TI paralela sea una práctica de TI más que puede encajar cómodamente en la función de arquitectura de TI.
En conclusión
Para que TI sea competente, debe realizar su trabajo utilizando procesos y prácticas 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 procesos que más necesitan el liderazgo personal de los CIO son la mesa de ayuda, el soporte de las aplicaciones y la gestión de la arquitectura de TI. Hay que pulirlos para que brillen y TI tendrá éxito --y será un éxito visible.
Eso es solo 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 hacen, no tendrán suficiente ancho de banda para pulir los tres grandes.
Basado en el artículo de Bob Lewis (CIO) y editado por CIO Perú
Bob Lewis es un consultor de gestión y TI de alto nivel, centrado en la eficacia organizativa de las TI y las empresas, la planificación de la estrategia a la acción y la integración de las empresas y las TI. Y sí, por supuesto, es digital. También se le puede encontrar en su blog, Keep the Joint Running.