Búsqueda


13 de octubre de 2006

El huevo, la gallina y el cliente que sabía demasiado

Tengo un cliente que sabe más que yo... en realidad sabe mucho más que yo y trabajar con él siempre me hace llegar a extremos insospechados. A este chico le bastan un par de frases para poner mi cabeza a trabajar hasta que echa humo, no se si le pasará a todos los que trabajan con él o simplemente es una característica de nuestra relación profesional.

Pues bueno, uno de estos extremos insospechados apareció hace un par de días cuando estábamos hablando sobre COBIT y la implantación que está llevando a cabo él en su organización. Me comentó que tuvo una charla con uno de sus compañeros, que le decía que COBIT era demasiado amplio y demasiado teórico como para conseguir implementarlo. De hecho la frase fue algo así como

-- "si no hemos conseguido estabilizar la puesta en marcha de los procesos principales de ITIL, ¿cómo vamos a pensar ahora en utilizar COBIT?"

a lo que este hombre le contestó:

-- "Si no te ha funcionado la implantación de ITIL es precisamente porque no tenías COBIT"

¡Toma bomba de relojería para mi cabeza! Me ha estado rondando un par de días, y sigue ahí metido el come-come.

Vamos a ver, esto se parece mucho a lo que comentaba en el artículo sobre madurez y gobernabilidad sobre el enfoque de "abajo a arriba" o de "arriba a abajo". Cuando haces el enfoque de abajo a arriba, resulta que te encuentras diseñando procesos con el objetivo de mejorar la forma en la que sirves los servicios TIC a la organización y después decides añadir el concepto de control para asegurar que los procesos se cumplen (osea, que la gente hace lo que has dicho en el papel que van a hacer) y para reducir el riesgo que te genera el tener los procesos descontrolados.

Pero... ¿es bueno diseñar los procesos sin control?

Según el propio modelo de proceso que muestran los libros de ITIL, una buena definición de proceso debe tener asociada su definición de proceso de control, y su reparto de roles, responsabilidades y recursos necesarios para la ejecución, así que a nada que empieces a funcionar, si no tienes proceso de control estarás navegando "a ciegas". Entonces, cuando diseñas el proceso has de tener en cuenta los objetivos del proceso y los controles que debes aplicar para asegurar su funcionamiento.

Pero ITIL no habla de controles, ni de indicadores de rendimiento (apenas) y cuando tienes que pensar en indicadores que te ayuden a saber si el proceso está logrando sus objetivos, la cosa se pone dura: o te los inventas (reinventando la rueda una y otra vez) o usas un modelo que te sirva para diseñar los que necesitas, y ese modelo se llama COBIT.

¿Y si quiero pensar en el diseño "de arriba a abajo"?

Entonces la cosa es más curiosa todavía... partimos de COBIT, y sus Objetivos de Control y nos encontramos con que tenemos (por ejemplo) un objetivo de control que dice "AI6 - Gestionar Cambios".

Como el objetivo de control no es el control en sí mismo, nos encontramos con que tenemos que pensar en qué controles definir para cumplir el objetivo de control Gestionar Cambios, y llegas univocamente a la necesidad de definir un proceso de Gestión de Cambios que cumpla, al menos, los objetivos de control detallados que propone COBIT.

Pero ¿puedo tener algo parecido a Gestión de Cambios sin tener proceso definido y en marcha?

¡¡Por Supuesto que Si!! Tendrás un Objetivo de Control XX en nivel de madurez 0.-Inexistente, pero lo tendrás.

Y aquí viene otra idea que me concome... ¿"Implementar COBIT"? ¿Acaso el COBIT se implementa? ... no se cómo explicarlo, porque es sólo un embrión de idea, pero es algo así como que COBIT ya está implementado en todas partes... solo que en muchos de los 34 procesos estás a nivel 0 de madurez. En todo caso el COBIT se usa, pero no estoy seguro de que se implemente.

Osea, lo que hay que plantear no es un plan de implementación de COBIT, sino un roadmap de maduración de los procesos críticos para tu organización: establecer la medición y el análisis de madurez necesario para saber dónde estás y cómo vas creciendo.

¿Y esos procesos críticos, son críticos para quien?

Buena pregunta. Busca los objetivos estratégicos de la compañia, hazlos corresponder con su mapeo en objetivos de la organización TIC, busca los procesos que hacen que esos objetivos TIC se cumplan y tendrás la lista de procesos críticos que has de madurar según los requerimientos del negocio... de esta forma harás madurar tus TIC alineadas con el negocio y el esfuerzo tendrá doble visibilidad.

En definitiva... ¿que es primero, el proceso que necesita un objetivo de control o el objetivo de control que te pide que tengas proceso?

Ya ves lo que hace tener clientes que saben tanto... te hacen pensar!!

¿Comentarios?

¿Opiniones?

¿Experiencias desde la trinchera?

Technorati tags: , ,

del.icio.us tags: , ,

2 comentarios:

Anónimo dijo...

Sin ningún tipo de duda, primero hay que tener el proceso, ni que sea parcialmente implementado, quiza con un nivel de control muy bajo (1 o 2 indicadores), y conforme este proceso madura se ve la necesidd de otros indicadores, que hay que implementar, y asi ayudar a madurar al proceso, en un ciclo de mejora continua hasta conseguir la excelencia. Y eso ha sido asi siempre, quiero decir en otros campos distintos de las TIC. ¿O acaso Henry Ford se preocupaba de poner navegadores en sus Ford T cuando lo que realmente le importaba era que el motor no se calentara demasiado?

Anónimo dijo...

Alisa

Cómo está usted, Antonio.
Leyendo esta entrada he notado que se refiere a "AI6 - Gestionar Cambios" como objetivo de control. Pero entonces, ¿no es considerado un proceso de TI?. Es mi duda, cómo debo tomar a las 34 definiciones, ¿como objetivos de control, o como procesos de TI?. También quisiera pedirle de paso, me aclarara a qué le llama CobiT Objetivos de control de alto nivel, es que, en el marco de trabajo no veo a qué se refiere esto. Sólo muestra los procesos de negocio, requemientos de negocio, declaraciones de control, prácticas de control, criterios, recursos de TI y el nombre del proceso de TI.