Los comienzos del cine tienen dos hechos curiosos. Pensamos que en los albores del celuloide, a finales del siglo XIX, sólo se hacían películas en blanco y negro y que el color vino mucho después. Pero no es así: algunas de las primeras películas de cine ya eran en color. Unos pocos meses después de que los célebres hermanos Lumière asombraran a un escaso público con la llegada de un tren, Edison presentó una breve película en la que la reconocida bailarina Annabel ejecutaba la llamada danza serpentina. Esta película tenía color.

Sin embargo, aquello no causó sensación. La razón era clara. Lo maravilloso del cine, lo que le hacía único y distinto de cualquier otro hecho cultural, era que representaba el movimiento. Mostrar colores no estaba mal, pero eso ya lo hacía la pintura. Por ver colores no se pagaba una entrada; ver el movimiento, sí tenía valor. Ésa es la esencia del cine: movimiento.

Hace unos meses se ha publicado una sorprendente encuesta de CIOnet reflejando las acciones que los CIO van a tomar en estos momentos tan apasionantes. Como cabía esperar, la reducción de costes es una prioridad inexcusable. Aquí se halla lo sorprendente. Con el fin de reducir los costes de las TI, la mayoría de los directores encuestados apuestan por acciones tales como revisar los contratos con proveedores o utilizar tecnología de comunicaciones que evite desplazamientos. Son como los colores en el cine: no está mal, pero eso ya lo hace cualquier departamento de soporte.

Si queremos sobrevivir como departamento de TI, tenemos que hacer cosas propias de la TI. Si hacemos lo mismo que hacen otros, nos verán como a otros. Si sólo llevamos a cabo acciones que puede hacer cualquier departamento de soporte, como es revisar los contratos con proveedores, se nos verá como a cualquier departamento de soporte. No se percibirá nuestro valor, porque así no lo tenemos, y en unos meses habrá un pliego de externalización.

¿Para qué sirven las TI? ¿Qué hace la función de TI que sólo ella haga? Mirando con detenimiento la esencia de su existencia, la función de TI tiene un doble cometido: asegura que los procesos de negocio actuales estén disponibles, y asegura que nuevas funcionalidades, o nuevos procesos de negocio estén disponibles cuando el negocio lo necesite. Esto es lo específico de las TI: esto es el movimiento en el cine.

El siguiente paso será medir este hecho único y propio de la TI para tenerlo controlado y determinar la eficacia de las acciones de mejora que se ejecuten en su favor. Por ejemplo, precisar el número de horas de productividad perdidas en el negocio por causa de un error en la TI. Reducir esta métrica significa disminuir costes de mantenimiento e incrementar la facturación del negocio. Por esto, el negocio sí paga una entrada para vernos.

De la misma forma que nos gusta más ver películas en color que en blanco y negro, además habrá que revisar los contratos con los proveedores. Pero esto será “además”. Si “sólo” nos dedicamos al color, es decir, a apretar a los proveedores, nadie verá nuestra diferencia con una hermosa pintura de un externo, que además es más barata.

El otro hecho curioso de los albores del cine radica en que en aquellos años el espectáculo no sólo era ver una cierta película, sino que incluso se enseñaba con emoción la tecnología que permitía tal maravilla, es decir: el proyector. Con el tiempo esa emoción ha desaparecido, y hoy en día nadie se asombra ante un cinematógrafo. Hagamos que no se pierda la emoción por la TI, a través de su único “movimiento”.

La TI tiene un doble cometido: asegura que los procesos de negocio actuales estén disponibles, y asegura que nuevas funcionalidades estén disponibles cuando el negocio lo necesite

Publicado en Computing, nº 609, 23 de septiembre de 2009

Una vez que Graham Bell patentó su teléfono en 1876, tuvo muchos problemas para vender su invento y hacer ver que aquello de transmitir la voz a través de un extraño artilugio era de utilidad. Por aquel entonces, los banqueros decían que tal ingenio bien podría servir para los tenderos, pero de muy poco a los banqueros. Por ello, la primera de red de teléfonos propiamente dicha vendría un año más tarde, enlazando cinco bancos. Dadas las reticencias de los banqueros a admitir en sus oficinas un aparato, para ellos, tan inservible, aquella primera red fue instalada gratuitamente, a modo de demostración, y por unas pocas semanas.

Actualmente se han olvidado aquellos comienzos tormentosos y la relación entre las TI y el sector financiero pasa por unos momentos de mayor dulzura. Según un informe de Quint [1], aproximadamente el 80% de las actividades de negocio de dicho sector tienen una relación directa con las TI. En España, el último informe “La Sociedad de la Información en España 2007” [2] de Telefónica, muestra que desde el año 2002, el 100% de las empresas del sector de servicios financieros y seguros tiene acceso a Internet.

En este artículo veremos cómo el Gobierno de la TI, a través de uno de sus elementos, el Cuadro de Mandos, puede hacer que las TI sigan siendo de interés para la banca (y no sólo para los tenderos).

El concepto de Gobierno de la TI

Que el Gobierno de la TI se llame “Gobierno” no es signo de barroquismo con ínfulas de grandeza. Tal nombre responde al hecho de que el Gobierno de la TI se encuentra dentro de lo que son las prácticas y regulaciones que conforman el Gobierno Corporativo de una empresa. Para entender cuáles son las “preocupaciones” del Gobierno de TI, podemos relacionar éstas con las “preocupaciones” de un Gobierno Corporativo (tabla 1 [3]).

Tabla 1: El Gobierno Corporativo y el Gobierno de TI [3]

Sobre estas ideas podemos desarrollar el modelo de gobierno de Peterson. Según dicho autor [4], el Gobierno de la TI se concentra en el doble propósito de contribuir a la operación y rendimiento del negocio presente y transformar y posicionar la función de TI para alcanzar los retos futuros del negocio.

Para llevar a cabo esta misión, Peterson establece que un Gobierno de la TI debe implementarse según un conjunto de estructuras, procesos y mecanismos de relación. Por estructuras entiende la existencia de un conjunto de responsabilidades, tales como la dirección de la función de TI o los distintos comités de TI que puedan existir dentro del Consejo de Dirección. Con los procesos se refiere a las actividades para la toma de decisiones y la medida del rendimiento. Finalmente, los mecanismos de relación ponen de manifiesto la necesidad de incluir la participación de la función de TI en el negocio, la existencia de un diálogo estratégico, el aprendizaje compartido, o una comunicación adecuada. Un ejemplo de estructuras, procesos y mecanismos de relación los podemos ver en la tabla 2.

Tabla 2: Estructuras, procesos y mecanismos de relación para la implantación del Gobierno de TI [4]

Un cuadro de mandos para el sector financieros

Según la tabla anterior, el Cuadro de Mandos es una herramienta más dentro del Gobierno de la TI, que afecta principalmente al ámbito de los procesos. No obstante, tal y como lo definen sus creadores, Kaplan y Norton [5], el Cuadro de Mandos es una herramienta de gestión, de medida del rendimiento y de comunicación. Esto quiere decir que con un Cuadro de Mandos cubrimos los tres ámbitos antes descritos: estructuras, procesos y mecanismos de relación; sin perjuicio de que debamos además tomar más acciones concretas en cada ámbito respectivo.

Para desarrollar un Cuadro de Mandos en el sector financiero, partiremos de una estrategia de negocio y veremos cómo se puede traducir en una serie de objetivos de TI que afecten a las cuatro perspectivas de un Cuadro de Mandos.

Volviendo al último estudio de Telefónica sobre la Sociedad de la Información en España, el primer obstáculo para el comercio electrónico por Internet es la inseguridad (34% de respuestas). Esto nos puede servir de punto de apoyo para definir una posible estrategia de negocio de una empresa del sector financiero: “incrementar la seguridad de los servicios financieros que se ofrecen en el portal de Internet de la empresa”.

Para desarrollar el Cuadro de Mandos, utilizaremos el Cuadro de Mandos para la TI que define Van Grembergen [6], el cual, en esencia, es el propuesto por Kaplan y Norton, cambiando la orientación de la perspectiva financiera por contribución corporativa, y la perspectiva de cliente, por perspectiva de usuario. Según esto, en la tabla 3 presentamos una serie de objetivos de TI, como ejemplo de un posible Cuadro de Mandos para cubrir la estrategia de negocio anterior.

Tabla 3: Objetivos de TI aplicados a las perspectivas de un Cuadro de Mandos

Esto es sólo un primer ejercicio de Gobierno de la TI, que debe ser completando con un adecuado mapa estratégico y un sistema de métricas que ofrezca luz sobre el rendimiento de los objetivos definidos.

No obstante, nos sirve para ver en qué medida las herramientas de Gobierno de la TI pueden contribuir a que éstas sigan ofreciendo valor al negocio. El 10 de marzo de 1876 Graham Bell transmitió la primera frase inteligible por su precario teléfono a su ayudante Watson, quien se encontraba un piso más abajo: “Sr. Watson, venga aquí, le necesito”.  La idea es que el sector financiero diga tan proverbial frase, cambiando “Sr. Watson” por “TI”.

Referencias

[1]   Mulder, M.Banking & Finance. Dossier. Quint Wellington Redwood, 2006.

[2]   Fundación Telefónica y Ariel. La Sociedad de la Información en España 2007. Diciembre, 2007.

[3]   Sheleifer, T. y Vishny, W. A survey on Corporate Governance. The Journal of Finance, 52(2), 1997.

[4]   Peterson, R. Information strategies and tactics for Information Technology governance, en W. Van Grembergen (Ed.), Strategies for Information Technology Governance. Hershey, PA: Idea Group Publishing, 2003.

[5]   Kaplan, R. y Norton, D.  Balanced Scorecard: Translating Strategy into Action. Boston: Harvard Business School Press, 1996.

[6]   Van Grembergen, W. Structures, processes and relational mechanisms for Information Technology Governance: Theories and practices en Strategies for Information technologies governance. Hershey: Idea Group Publishing, 2003.

Publicado en A+ Auditoría y Seguridad, No. 29, febrero, pp.146-147, con el título «IT Governance en el sector financiero»

El Titanic y la estrategia en ITIL v3

El 14 de abril de 1912 el Titanic chocó contra un iceberg, con las consecuencias catastróficas que todos conocemos. El fatídico encuentro de la nave con el bloque de hielo fue consecuencia de una mala gestión de los procesos relacionados con la TI. Quién sabe si con ITIL v3 la situación podría haber sido otra.

A las 04:25, hora universal, Jack Phillips, el primer operador de radio del Titanic, le espetaba la frase que encabeza este artículo de manera poco amable al operador del barco Californian. Media hora más tarde, el mismo telegrafista lanzaba sus mensajes agónicos de socorro. El choque del Titanic con el iceberg fue debido a una estrategia errónea en la gestión de los procesos relacionados con las TI. Situación que posteriormente fue enmendada en la Conferencia de Radio de Londres de ese mismo año. De aquella amarga experiencia, producto del azar y la soberbia, podemos extraer una enseñanza para la gestión de los procesos de las TI según las buenas prácticas de ITIL v3.

Los procesos del Titanic

Aquella noche del 14 de abril los telegrafistas del Titanic estaban inmersos en sus tareas diarias de comunicación. Se encontraban trabajando con MCE, indicativo de radio de la estación costera Cape Race, con quien tenían un frenético intercambio de mensajes. El Titanic enviaba a la costera los telegramas dejados la víspera por el pasaje en la oficina postal del barco, mientras que la costera hacía lo propio con los telegramas dirigidos al barco. Podemos decir, que se estaba llevando a cabo un proceso batch.
Dada la expectación creada con aquel viaje inaugural, cabe suponer que el tráfico de telegramas era considerable y la premura intensa. La mala contestación que recibió Evans, telegrafista del Californian, responde a la presión de tan exhausta actividad. El telegrafista del Californian le acababa de enviar un mensaje al Titanic indicándole que por la zona en la que navegaban se habían visto grandes bloques de hielo.

Podemos entender la irritación de Jack Philips, quien abrumado por aquel sin fin de telegramas, era interrumpido con mensajes impertinentes. “Espérate, estoy trabajando MCE”, fue su arrebato incontenible. Evans, contrariado, apagó su emisora, lo que impidió que posteriormente escuchara los mensajes de socorro. Se daba la circunstancia de que el Californian se encontraba relativamente cerca del Titanic.

Tiempos de silencio y escucha

En la Conferencia de Radio de ese mismo año se tomaron medidas para evitar, en la medida de lo posible, tan dramáticas catástrofes. Se establecieron los llamados periodos de escucha y de silencio con una duración de tres minutos cada media hora. Durante tales periodos, los telegrafistas tenían que abandonar por completo su actividad habitual y sintonizar la frecuencia de emergencia para poder escuchar una posible señal de socorro que un barco la estuviera transmitiendo con poca potencia, precisamente en la frecuencia internacional de emergencia. Desde entonces, en el cuarto de radio de cada buque se podía ver un reloj con unas marcas especiales de color rojo y verde, en unos minutos determinados, que señalaban la existencia de tan críticos momentos.

ITIL está orientado a proceso, y en ello reside su grandeza, a la vez que desgracia

La importancia de los procesos en ITIL v3

Hoy en día los avances en seguridad marítima han dejado en el olvido los periodos de escucha y silencio. No obstante, su esencia nos puede seguir siendo relevante.

ITIL está orientado a proceso, y en ello reside su grandeza, a la vez que desgracia. Trabajar en una orientación a proceso significa compaginar la actividad propia de un departamento de las TI, con la actividad específica de un proceso. ¡Qué grandeza!, pues toda la TI es susceptible de trabajar de forma global en un momento dado en un proceso que afecte a un servicio de negocio. ¡Qué desgracia!, pues la experiencia en las implantaciones de ITIL nos habla de las dificultades que ello conlleva. El trabajo desbordante del día a día, la misma premura que llevó a la iracundia al telegrafista del Titanic, es el actual ladrón del tiempo de los procesos y la semilla del fracaso en la implantación de las mejores practicas de ITIL.

Con ITIL v3 tenemos una oportunidad inexcusable para buscar tal compromiso de la Dirección

La solución a tal dilema la podemos encontrar en los momentos de escucha y de silencio. Tales momentos se establecieron ante la innegable importancia del proceso que podemos denominar “Salvar vidas humanas”. Si pensamos que ITIL es importante para entregar a nuestros clientes los mejores servicios de TI, deberemos establecer también una especie de momentos de escucha y de silencio para nuestros procesos de ITIL. No será cuestión de colgar un reloj con marcas verdes y rojas en nuestro CPD. Será responsabilidad de la Dirección respaldar la importancia de tales procesos ofreciendo un entorno adecuado de trabajo y una redistribución de tareas que permitan tales tiempos de escucha y de silencio. Sólo si pensamos que ITIL es importante.

Con ITIL v3 tenemos una oportunidad inexcusable para buscar tal compromiso de la Dirección. Es en la nueva versión de ITIL donde se dedica espacio a una serie de procesos relacionados con la estrategia del negocio (Service Strategy), cuestión que en la anterior versión no aparecía tan clara. Hablar de momentos de escucha y de silencio es hablar de estrategia; de relacionar la estrategia del negocio con la estrategia del departamento de TI, y de extraer líneas directrices que gobiernen el desempeño del resto de procesos. ITIL v3 abre la puerta a una serie de mecanismos que pueden evitar el tener que lanzar nuevos mensajes agónicos de socorro y llevar al ocaso a una organización, aunque ésta se deleite en su hundimiento con sublimes melodías de su heroica orquesta.

En descargo de John G. Phillips y Harold Bride, telegrafista primero y segundo del Titanic respectivamente, debemos decir que el mensaje de aviso de icebergs que envió el Californian, por el cual recibió tan amarga contestación, parece que fue enviado erróneamente. No fue encabezado con el código MSG, que indicaba la necesidad de remitir inmediatamente el mensaje recibido al capitán. Fue una incidencia mal codificada; pero esa es otra cuestión.

Publicado en Techweek 

P.D.: si quieres saber algo más de las comunicaciones del Titanic: Booth, J & Coughlan, S. Titanic – Signals of Disaster. White Star Publications, 1993.