Llegamos a ustedes gracias a:



Columnas de opinión

El CIO que no quiere ser

Por: Al Kuebler, consultor en gestión general y problemas de TI

[13/12/2010] A veces se encuentra con una persona que lo impacta como un modelo inspirador. Otras veces se obtiene un modelo de manera diferente, un ejemplo de cómo no ser. El CIO con el que acabo de pasar una hora, sin duda, fue del segundo tipo.

Un cabo en uniforme de general, me dije a mí mismo. Previamente me había dado cuenta que él nunca había desarrollado en realidad ninguna aplicación de software en su carrera, y ciertamente parecía no saber cómo dirigir o delegar esta responsabilidad ahora. Cuando se trataba de armar un plan de trabajo de TI, construir y ejecutar, era bastante capaz de mantener las cosas funcionando, pero no tenía idea de cómo planificar y construir. Él, probablemente, no consiguió su puesto a la primera; y parecía que me habían contratado para asegurarse se que no se quedara mucho tiempo.
Esto ocurrió durante mi carrera como consultor. Había sido contratado por el director gerente de una unidad estratégica de negocios de una compañía grande, que tenía problemas en sus relaciones con el departamento central de TI.
Eran muchos los problemas, como que TI incumplía los niveles de servicio acordados y no parecía importarle. Pero lo que provocó que me llamaran fue la casi imposibilidad de conseguir software desarrollado o modificado.
El departamento de TI no respondía y se había vuelto burocrático, levantando un muro de piedra diciendo que trabajaría en el desarrollo de aplicaciones de software solo después de que la unidad de negocios documentara los requerimientos de sistema.
"No sé lo que es un requerimiento de sistema o cómo documentar uno", me dijo el director gerente. "Y la última vez que puse a mi gente a intentar hacer eso, el departamento de TI contestó los escritos meses más tarde con una lista de las cosas que habíamos omitido o que pensaban que no funcionarían", explicó.
Su exasperación se basaba en consideraciones comerciales. "Estamos perdiendo negocios", señaló. "Sabemos cómo abordar nuestros problemas con una mejor tecnología, pero estamos atascados, porque la burocracia de TI evita que se haga cualquier cosa", detalló.
Después de darme más detalles, tenía una imagen bastante clara del departamento de TI con mentalidad de bunker. No es algo raro, lamentablemente, quizás porque hay muchas cosas que pueden contribuir a ello.
En algunos casos, simplemente TI tiene un presupuesto muy limitado y no hay manera de dar prioridad a los gastos de desarrollo, por lo que plantea obstáculos para impedir otros nuevos. Otras veces, TI se ha quemado gravemente después de sumergirse en un gran proyecto de desarrollo con especificaciones inadecuadas. O tenía insuficientes recursos o había perdido el talento necesario para desarrollar nuevas aplicaciones, o era incapaz de comunicarse con las unidades de negocios o de involucrarse en los asuntos de las unidades de negocios. No importa cual sea la causa de una mentalidad de búnker, el resultado ha sido siempre una relación que rayaba en la contradicción con los clientes de TI.
El director gerente estaba dispuesto, si era necesario, a hacer una carrera final alrededor del departamento interno de TI para conseguir lo que él necesitaba. Él confiaba en que el CEO lo respaldaría. "El tiempo es el mejor amigo de nuestros competidores ahora, y el CEO lo sabe, me dijo.
Pasé algún tiempo familiarizándome con las necesidades de desarrollo de sistemas del director general, y luego me reuní con el CIO. Lo que encontré fue un matón políticamente astuto, melodramático y teatral. Era una oscura amenaza y me preguntó por mis calificaciones, los resultados que había conseguido y la persona que había contratado mis servicios. Se volvió menos oscuro cuando se enteró de que el CEO sabía acerca de mi misión.
Al parecer, creyendo que podía hacer desaparecer todo con una feliz charla cuidadosamente redactada, me dijo que su departamento de TI y las unidades de negocio formaban un equipo. Pero su lenguaje corporal sugería que solo quería que la reunión terminara. Mi suposición era que él moría de ganas de conseguir un mensajero que le diga al CEO que evalúe el daño que se le había hecho a su carrera.
Yo estaba más entretenido que irritado por su comportamiento, sobre todo porque era tan transparente, a pesar de que parecía seguro de que se trataba de una actuación convincente. Sin embargo, le dije: "Yo entiendo que tiene una estricta política de que los clientes internos deben escribir sus propios requerimientos de sistema, sin la cooperación de TI, esperando que este enfoque retrase los resultados ¿Por qué hace las cosas de esa manera?". Para mí, se trataba de una pregunta natural, porque realmente no podía entender cómo esta política podría ser considerada como una buena idea. En mi experiencia, los requisitos de los sistemas se desarrollan mejor en forma conjunta, con los profesionales de TI y especialistas de negocios trabajando juntos. Entonces, el software puede ser entregado en etapas dependiendo de la prioridad, a fin de evitar implementaciones complejas de alto riesgo, de todo o nada.
Lo que esta pregunta originó fue algo increíble de oír. En primer lugar, el CIO cuestionó cada supuesto detrás de mi consulta. Lo que él quería era que nombrara a mis informantes y que le señalara que dijeron exactamente. Por último, quería saber si había sido mencionado expresamente.
Yo le contesté con ecuanimidad (mientras que él me había contestado que no a todo), y luego farfulló, "Este es un asunto serio para mí y ahora que estoy consciente de ello, lo voy a convertir en mi prioridad". Para mostrar cuán seriamente tomaba el asunto, agregó: "Cuando llegue al fondo de esto, tendré que empezar de nuevo, con gente nueva".
En resumen, todo había sido un fracaso por parte de cualquiera que no sea él, y él no dejaría de castigar a los malhechores.
Entonces, al despedirme pensé que este ejecutivo se iba a asegurar de que rodaran cabezas, para demostrar a todos que tiene todo bajo control. Fue una respuesta completamente equivocada.
Opciones
Tuve una entrevista de salida con el director gerente y otros dos ejecutivos de alto nivel de otras unidades de negocio.
"El CIO llamó y me preguntó por qué no le había informado directamente acerca de mis problemas con su equipo", nos dijo el director gerente, más que un poco divertido. "Él dijo que si él hubiera sabido acerca de nuestros retrasos, se podría haber evitado todo esto. Yo le dije que le había dejado tres mensajes con su secretaria durante la debacle de la redacción de los requerimientos sin una llamada de vuelta, y que me di cuenta de que él había firmado todos los documentos burocráticos -y que eran una pérdida de tiempo- en ese intercambio ridículo. Por lo tanto, le pregunté, ¿cómo podría no saber acerca de esta situación? También le dije que se suponía que debía estar ejecutando un servicio enfocado en el cliente corporativo interno, y que las unidades de negocio eran sus clientes. Sugerí que él y su equipo comiencen a tratarnos de esa manera".
Los otros altos ejecutivos fueron alentados por el informe de este intercambio, pero ya era hora de ponerse a trabajar. El director gerente se volvió hacia mí y preguntó: "¿Qué hay que hacer aquí?"
"Yo veo tres opciones", le dije. "En primer lugar, el CEO podría ordenar al CIO que proporcione servicios de TI de nivel comercial en los cuales planifiquen, construyan y ejecuten todos los servicios a menor costo que proveedores externos. La segunda opción sería la creación de una excepción que permita a las unidades de negocio hacer uso de los desarrolladores externos cuando el departamento de TI interno no puede prestar su servicio en el momento oportuno Por último, está la opción de dejar las operaciones corporativas de cómputo -la pieza de ejecución de TI- centralizada, mientras mueven al personal de desarrollo de aplicaciones de software dentro de las unidades de negocio.
Yo habría añadido que pensaba que la primera opción era la forma más clara, por muchas razones, no menos importantes que los puntos de vista de los accionistas. Pero antes de que pudiera hacerlo, se puso de manifiesto que los gerentes de negocios ya habían acordado en un curso de acción similar.
Al final, el CIO terminó reportando a un nuevo CIO que era competente en colaboración con las unidades de negocio a las cuales servía el departamento de TI.
Entonces, ¿qué?
Si es un CIO que habitualmente no se reúne con los jefes de cada unidad estratégica de negocios a las cuales sirve, a fin de conocerlos personalmente y evaluar su desempeño en las funciones de TI antes de que haya una crisis, está limitando su carrera.
Es necesario ser conscientes de hasta la más mínima manera en la que puede mejorar la función de TI como contribución estratégica a la empresa y a cada unidad de negocio dentro de ella. Necesita estar en contacto, de modo que pueda ser eficaz en el tratamiento de problemas antes de que se vuelvan críticos.
Y un estilo de gestión autoritario es contraproducente y, en última instancia, de corta duración, por la sencilla razón de que nadie quiere pasar tiempo con alguien que lo emplea. Se trata de personas desagradables, incapaces de intercambiar conocimientos y sabiduría de forma constructiva o de construir un enfoque conjunto.
Soy partidario de la definición de Joel Barker de un líder: "Alguien que uno elige para seguirlo a lugares que no iría de otra forma. Incluso si tiene la idea de que este CIO brillaba por su ausencia, no debe confiar nunca en un estilo de gestión autoritario. Los que reportan a los gerentes y emplean este concepto, nunca son considerados líderes.
Computerworld (US)
Al Kuebler fue CIO para AT&T Universal Card, Condado de Los Angeles, Alcatel y McGraw-Hill (MHP), y director de ingeniería de procesos en Citicorp. También ha dirigido la actividad de consultoría para CSC Europa. Actualmente es consultor en gestión general y problemas de TI, así como ponente en las escuelas de postgrado de la Universidad de Nueva York, De Paul y la Universidad de Chicago. Es autor del libro Técnica del impacto: Cómo hacer que su tecnología de la información sea eficaz, y se mantenga de esa manera, de la cual se extrajo este artículo.