Espérate, estoy trabajando con MCE

por 21 Jul 2008Estrategia

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.

 

 

Pin It on Pinterest