Búsqueda


31 de octubre de 2006

Reflexiones desde el cielo

Hoy escribo este post a 10.000m de altura y a 1.000Km/h, el post más rápido que he escrito nunca!!

Me encanta volar. Odio las esperas en los aeropuertos y más aún las ocasionadas por retrasos inexplicados como el de hoy, pero cuando el avión comienza la aceleración en la pista y me siento aplastado contra el asiento se me pasa todo y ya, cuando despega y puedo ver por la ventanilla el espectáculo desde el aire, entonces es cuando me quedo colgado mirando y mirando.

El despegue de hoy ha sido especialmente bonito; el aeropuerto de El Prat estaba cubierto de niebla y el piloto se ha dado prisa en subir, poniéndonos con una inclinación que yo creo que era de más de 30º... de repente hemos atravesado la capa de nubes y allí estaba la luna iluminando desde arriba el mar de nubes. Especialmente bonito.

Me gusta ver el paisaje desde arriba y cuando el vuelo es nocturno, más aún ver las formas caprichosas que dibujan los alumbrados de las calles, los focos de las fábricas y hoy, además, he tenido la oportunidad de ver los haces de luz de una discoteca desde arriba!

Desde la distancia las cosas se ven diferentes. Los pueblos se parecen entre ellos y todo se funde, se mezcla, se homogeneiza (se dirá así?).

Mariano me tiró un lance, a ver si lo pillaba. Hace mucho tiempo me preguntó si podríamos usar ITIL para otras cosas que no fueran las TIC, y no le contesté. Como él dice, la respuesta, o era trivial, o era complicadísima... se me hacía pesado contestarle por lo largo y meditado de la contestación porque, claro, ITIL son buenas prácticas para gestionar servicios TIC y no para gestionar cualquier cosa. Sin embargo, siempre que haya un servicio podremos generalizar ITIL para construir unas buenas prácticas de gestión... al menos los nombres de procesos, estructura, relaciones.

Luego, meses más tarde, escribí un artículo sobre COBIT y Mariano volvió al ataque, esta vez más ilusionado aún porque veía que realmente podría extrapolar la idea hacia su mundo particular del sistema educativo. ¿Por qué le llamó más la atención COBIT que ITIL? ¿Por qué no dudó lo más mínimo en reinventar el concepto de Gobierno de las TIC y el Gobierno Educativo?

Porque a vista de pájaro las cosas son diferentes. COBIT es un modelo mucho más abstracto que ITIL y también mucho más generalista... y la definición de Gobierno Corporativo ya es el extremo de la generalidad, y es por eso por lo que ha podido aprovecharlo para su modelo propio de Gobierno Educativo.

Para poder extrapolar ahora el resto de COBIT e ITIL hacia un modelo que sirva de marco de referencia para la gestión de otras cosas (un sistema educativo, un centro o una cadena de restaurantes) yo creo que hay que quedarse con los títulos más importantes, usar ITIL y COBIT como el índice de tu marco de trabajo definiendo:

  • Definición de objetivos de negocio.
  • Los procesos que se deben dar para conseguir la gestión adecuada del tipo de servicios que se proporcionan incluyendo (para no caer en los mismo errores de antaño) todos los procesos que cubren el ciclo de vida completo del servicio: desde la gestión de la demanda, el alineamiento con los objetivos estratégicos de la organización, la construcción, la producción y el mantenimiento de la vida productiva del servicio.
  • Mapeo de los objetivos de negocio sobre la lista de procesos
  • Los indicadores, que deben servir para medir el grado de cumplimiento de los procesos, el volumen y rendimiento en la actividad de los procesos y el nivel de madurez de la implantación de cada uno de los procesos anteriormente detallados.
  • Los roles, responsabilidades y habilidades necesarias para cada una de las actividades o funciones dentro de los procesos.
  • Las relaciones entre los procesos.

No se, así a priori y desde un avión es lo que se me ocurre a voz de pronto para definir el marco de trabajo.

Luego vienen las guías de implantación, o sea las prácticas recomendadas por el sector como apropiadas para la ejecución de cada uno de estos procesos y para el orden de implantación; y cuando esto se haya convertido en algo extendido y aplicado entonces viene el trabajo de definir el benchmarking: ¿cuales son los valores habituales considerados como correctos para los indicadores definidos anteriormente? y los formatos de representación: ¿cuál es la forma más común de representar estos indicadores de forma que sean útiles al máximo número de personas en la organización?

¿Con esto estamos aplicando ITIL o COBIT para la gestión de otro tipo de servicios? No exactamente... estamos replicando la forma de crear un marco de trabajo para definir el marco adecuado para el tipo de servicios que queremos gestionar/controlar.

¿Te sirve como respuesta, Mariano, o una vez más he volado demasiado alto?

28 de octubre de 2006

Obesidad Cognitiva

Hoy volvía del trabajo en el coche e iba oyendo la radio. Normalmente oigo emisoras de música, pero hoy no se por qué razón me dió por jugar con el dial y llegué a una emisora en la que un señor hablaba de serpientes. Como era de esperar semejante temática captó mi atención de golpe, así que me quedé en esa emisora que luego resultó ser Radio 5.

El locutor estaba haciendo algo así como una crítica literaria y estaba hablando sobre un autor que había escrito un capítulo titulado Con respecto a las serpientes y resulta que en el capítulo este se acababa concluyendo que en la isla no había serpientes.

Luego vino la reflexión del locutor (que ha sido realmente lo que me ha llevado a escribir esta historia): ¿Porqué el autor no escribió otro artículo al respecto de los hipopótamos concluyendo que no existían hipopótamos en la isla? ¿o un "Acerca de los dinosaurios"? o incluso un "acerca de los rinocerontes"...

Simplemente porque había gente que pensaba que en la isla sí que había serpientes y lo importante era constatar el hecho de que no las había. Es decir, constatar lo que no existe es tanto o más importante que declarar lo que sí que existe.

En ese mismo instante a mí se me iluminaron dos bombillas en la cabeza:

  1. La gestión de cambios. El análisis de impacto. Hemos de pensar en el impacto que tendrá el cambio sobre servicios y usuarios si lo implementamos, y hemos de pensar en el impacto de la NO ejecución del cambio, para poder tomar correctamente la decisión de si ejecutarlo o no.
  2. Pero la gestón de cambios está poco relacionada con nuestro autor. La segunda bombilla fueron las auditorías: constatar lo que no existe (es decir, aquello que necesitamos que exista, pero no tendremos evidencia) es tanto o más importante que declarar lo que sí existe (aunque esto que sí existe esté mal).

Me dió que pensar el locutor de Radio 5. Me impactó con sus ideas y en el siguiente semáforo apunte en un papelote los conceptos que se me habían quedado en la cabeza (lamentablemente ni el nombre del locutor ni el del programa para poderlos citar aquí) y ese papel tiene las siguientes frases:

  • Radio 5
  • Horrebow
  • Ideas Basura
  • Comida Rápida
  • Obesidad cognitiva
  • Teoría Unificada
  • "Acerca de las Serpientes"

Seguramente a estas alturas del artículo te ha crecido la curiosidad y necesitas saber más cosas, como por ejemplo ¿de qué isla y de qué libro estaban hablando? o ¿Por qué el título de Obesidad Cognitiva?

La obra y el autor serían fáciles de encontrar para cualquiera, ya que tuve la suerte de apuntar bien el nombre del autor, que después según el Sr. Google resultó ser Niels Horrebow. Este señor fue un naturalista danés que en el siglo XVIII escribió una Historia Natural de Islandia en la que incluyó tan famoso capítulo e incluso hoy podemos encontrar múltiples referencias al hecho de que en Islandia no hay serpientes, pero supongo que ninguna al de que no hay leones ni marcianos.

¿Y el título?

En realidad el locutor comenzó a divagar un poco explicando que hoy en día el ser humano dispone de un volumen de información brutal. Los medios de comunicación, Internet, libros, revistas, etc. bombardean nuestras cabezas una y otra vez con toneladas de ideas que se podrían interpretar como ideas basura servidas por medios de comunicación que preparan la información como si de comida rápida se tratara.

Los consumidores de esta información basura, si son demasiado asiduos a este tipo de "alimento para el alma" y no son críticos ni selectivos acaban teniendo una sobre-información que no les conduce a nada bueno y a este concepto le llamó obesidad cognitiva. A mí me gustó el término, y por eso me quedé con él para titular este artículo.

No se, le veo tanta relación con el artículo sobre la sobrecarga informativa que es interesante ver como se van enlazando los conceptos a lo largo de la vida.

Bueno, les dejo con este bombardeo de ideas y, sobre todo, piensen en sus auditorías. ¿Se plantean lo que NO HAY?

Esto da para un buen rato de disertación, porque lo que "no hay" es "lo que falta". Si estamos auditando el cumplimiento de una norma estricta, está claro que los elementos de la norma deben estar todos y cada uno y si no existe alguno, documentamos una evidencia.

Pero... y si lo que "no hay" es en realidad "lo que debería haber", no según el criterio de una norma, sino según el criterio del auditor? Entonces se convierte en una auditoría / consultoría, que es lo que la mayoría de clientes con los que he trabajado este tipo de ámbitos quieren, desean y te piden.

Es un poco tarde (02:02)... ¿Dejamos la diseración sobre auditoría o auditoría/consultoría para otro día?

23 de octubre de 2006

Métricas, métricas y más métricas

Las métricas se ponen de moda... una vez que las organizaciones comienzan con las implantanciones de sistemas de gestión de procesos, procesos de gestión de sistemas, servicios gestionados o procesos de gestión de servicios o como quiera que le hayan llamado a la última reorganización del departamento de IT con el objetivo de dar un mejor servicio al usuario, siempre llega el momento de medir. Al fin y al cabo, va implicito en la propia palabra, ¿no? Queremos dar un mejor servicio al usuario, y mejor quiere decir...

¿Qué quiere decir mejor?

Si no tengo medidas, mejor es una palabra vacía, o cuando menos subjetiva. De ahí la gran importancia de la medida.

medir.

(Del lat. metīri).

1. tr. Comparar una cantidad con su respectiva unidad, con el fin de averiguar cuántas veces la segunda está contenida en la primera.

Así de simple. Comparar algo con su respectiva unidad, así que necesito la unidad, y la cantidad (o cosa a medir). Las unidades son fáciles, lo malo es conseguir las medidas. Hay que decidir cuáles son y hay que ponerse de acuerdo, además, en cómo obtenerlas.

En estos últimos meses las métricas se están poniendo de moda. Supongo que precisamente se debe estar notando la gran capilaridad que han tenido las implantaciones de procesos tipo ITIL durante el año pasado y principios de este, en que el mercado ha estado muy revuelto, un gran número de organizaciones han superado las tres primeras etapas de decidir, pensar e implantar los primeros procesos y ahora viene lo siguiente, que es medir.

Y cuando la gente quiere medir, lo siguiente que quiere es representar las mediciones en un Cuadro de Mando y entonces es cuando viene el problema, porque no te piden medir, sino un CdM, un BSC o un QdC (que al fin y al cabo es todo lo mismo pero en distinto idioma).

¿Se puede tener un Cuadro de Mando sin medir?

Rotundamente no. Es necesario establecer las métricas que se deben recolectar, la forma de agruparlas y la forma de representarlas... pero lo primero es definir y recolectar métricas.

¿Y quién me ayuda a esta definición?

Pues debes pensar en un par de cosas primero y después acudir a la bibliografía existente, a saber:

¿Alguna Recomendación?

Si, tengo un par de recomendaciones que hacer:

1.- No por mucho medir amanece más temprano: Es mejor tener un conjunto reducido de métricas pero muy fiables, bien calculadas y bien obtenidas que un catálogo de métricas enorme de grande pero poco fiable. El proceso de obtención de la métrica, la fuente de información, el proceso de almacenamiento y representación, todo debe ser estable, controlado y fiable. Sobre todo la fuente de información... así que se deben establecer los controles apropiados para garantizar la fiabilidad en el propio origen. Piensa en COBIT para ello.

2.- Piensa qué quieres medir: ¿Quién es el destinatario de la métrica? ¿Qué quieres hacer con estas medidas? Preguntas importantes a hacerse antes de liarse a medir... si quiero medir el proceso para mejorarlo debo aplicar medidas al proceso, normalmente serán medidas internas (no serán mostradas al cliente) y sirven para corregir y ejecutar el plan de mejora contínua sobre los procesos. Si, por otra parte, quiero dar datos al cliente, entonces lo que necesito son medidas sobre el servicio, medidas extremo a extremo y que normalmente formarán parte del proceso de Gestión de Niveles de Servicio. Si, finalmente, lo que necesito son medidas para la explotación de los sistemas, entonces necesitaré métricas muy tecnológicas que estarán fuertemente ligadas a los componentes físicos sobre los que se proporciona el servicio.

3.- Categoriza las métricas: yo normalmente aplico grandes categorías para la clasificación y presentación de las métricas, a saber:

  • Métricas de Calidad: indican la calidad del proceso o servicio y tienen que ver con aspectos en la provisión (por ejemplo, tiempo de respuesta).
  • Métricas de Volumetría: indican cantidad, volumen de uso o de producción y se suelen usar para poner las cosas en contexto (siempre los ANS deben ir ligados a un contexto de volumetría de uso del servicio, por ejemplo).
  • Métricas de Disponibilidad (para los servicios)
  • Métricas de Cumplimiento: para la gestión de los procesos, no sólo necesitamos rendimiento o volumen del proceso sino algo que nos indique el grado de acercamiento a los objetivos de calidad del proceso en sí, lo que COBIT llama KGIs.

¿Y luego?

Luego viene la parte más difícil, que es medir. Obtener todas y cada una de las métricas para posteriormente reflejarlas en un informe, una web o un Cuadro de Mando es una tarea titánica que puede resultar ser virtualmente imposible si la tecnología no nos ayuda. A veces hasta la métrica más simple se puede volver un infierno si las máquinas no están de nuestro lado. Yo siempre propongo estudiar qué métricas podemos obtener "ya mismo" y cuáles podemos obtener a medio/largo plazo. Para cada una de ellas habrá que hacer una estimación de costes para saber cuánto nos va a costar obtenerla, luego hay que tomar las decisiones y por último llevar a cabo el proyecto que nos permita obtener el mecanismo de medición. (fíjate que he utilizado la palabra proyecto!)

Otra de las grandes problemáticas que aparecen es dónde y cómo guardar estas métricas. Aquí es donde se unen los mundos ITIL y BI y comienza la fiesta de verdad: un mundo apasionante.

En Definitiva

¿Tu empresa tiene un cuadro de mando financiero o un datawarehouse de ventas? ¿Cuánto tiempo/esfuerzo/dinero ha costado hacerlo? Pues piensa que si pides un BSC para las TIC estás entrando en un terreno que utiliza exactamente los mismos criterios, pero aplicados a fuentes de datos tan heterogeneas como tus servicios y procesos TIC.

Es útil. Es importantísimo. Es vital tenerlo, pero al mismo tiempo es costoso y laborioso. Pero ¿Acaso toda empresa más o menos grande no necesita un ERP o un sistema de gestión?

LAS TIC TAMBIEN LO NECESITAN.

17 de octubre de 2006

El "estilo campechano" triunfa

Corria Septiembre del 2006 cuando escribía el artículo ¿Formalizar o Improvisar? en el que se hablaba de los diferentes estilos de aproximación a una implantación de ITIL y hoy he podido comprobar que escasamente dos semanas antes, todo un gurú como Brian Johnson, identificado en el pie de pagina del artículo como

Brian Johnson is one of the original authors of the first ITIL books and an ITIL worldwide practice manager at CA Inc. He has also authored more than 15 books on ITIL or related topics and is the founder of the IT Service Management Forum, a professional organization focused on IT service management and ITIL.

escribía el artículo A practical approach to implement ITIL practices donde precisamente dice una frase magistral:

In the end, the cure for the common cult of "ITIL by the book" is ironically practical ITIL, successfully implemented.

Vamos... que no se puede sacar ITIL del libro y ponerlo directamente en ejecucion, que previamente hay que pensar un poco!!

15 de octubre de 2006

Sobrecarga informativa

No sé muy bien cómo llegué a este sitio, seguramente siguiendo gran parte de su algoritmo de des-navegación por Internet. Ahora bien... me ha parecido real como la vida misma y digno de ser enlazado directamente, sin necesidad de que un artículo completo a su alrededor aporte algo más o de una nueva visión sobre el tema.

Así, a pelo, aquí teneis a Pedro Murillo y su excelente artículo.

Hoy va de encuestas

Hay una serie de preguntas que siempre se hacen los clientes, y que normalmente aparecen en los cursos de formación si el alumnado es de nivel o tiene experiencia. Yo respondo a estas preguntas según mis experiencias personales, pero me quedo con la duda de si, al ser un entorno más o menos endogámico, no estaré viciado en mis respuestas.

Así que vamos a comenzar una tanda de encuestas a ver qué resultados podemos obtener entre todos. Lo subrayo porque como tengamos el mismo éxito que con la encuesta sobre el forum, lo llevamos claro! (han pasado por este blog al menos 300 visitas y sólo tenemos 6 votos de los cuales al menos 2 son míos, así que ya ven.. menos de un 1% de participación, que es más o menos acorde a los resultados de lo que publica Jakob Nielsen en su informe sobre la falta de participación en las comunidades online)

Encuesta número 1: ¿En qué orden comienzas la implantación de procesos?

No puedo poner todas las posibles combinaciones, pero se presentan algunas de las más comunes. Si no, en los comentarios puedes añadir tu propio orden.


Create polls and vote for free. dPolls.com

Encuesta número 2: ¿Todos los procesos para un servicio o todos los servicios para un proceso?

Si imaginamos una tabla en la que cruzamos los procesos que podamos tener implantados con los servicios del catálogo de servicios, ¿Cómo haces la implantación, por filas, por columnas o por celdas dispersas?

Es decir, coges un proceso concreto y lo implantas para todos los servicios que proporcionas o bien coges un servicio concreto y a este le aplicas todos los procesos?


Create polls and vote for free. dPolls.com

Encuesta número 3: Al definir la Gestión de Configuraciones, ¿En qué momento creas el CI en la CMDB?

Lo creas en el momento de la petición, de la compra, de su detección? Aquí has de todo un poco y en cada casa se hace diferente... ¡¡cuentanos cómo lo haces!!


Create polls and vote for free. dPolls.com

PD1: Gracias, Tomás, por inspirar la idea de las encuestas.

PD2: Este post requiere de la participación de todos los que lo lean. A partir de tus respuestas podremos sacar conclusiones válidas para todos.

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 de octubre de 2006

La madurez como prerrequisito para IT Governance

Este fin de semana vinieron a casa un par de parejas de amigos a tomar el aperitivo. Estuvimos hablando de todo un poco, como pasa siempre en estos casos, y uno de los temas que salió fue el caso de un mando intermedio en la empresa de uno de ellos que estaba perdiendo el correcto funcionamiento del departamento (de ventas) y que para ocultarlo estaba "apañando" las estadísticas de resultados.

En el mismo momento en que lo estaban contando y, a pesar de que el susodicho personaje estaba cometiendo otras faltas que humanamente me parecían peores (el mobbing es una práctica despreciable desde mi punto de vista), la idea de un mando intermedio manipulando las estadísticas me pareció interesantísima como ejemplo para comentar en clase.

Claro, el primer concepto que ejemplifica este comportamiento es el de la Segregación de Funciones: ¿A quién se le ocurre que las métricas que evalúan el correcto funcionamiento de una Unidad Organizativa las genere manualmente el propio responsable de la UO? Y si además al responsable de la UO le va parte del sueldo variable en ello, ¡peor aún!

Ahora bien, el meditar sobre esto fue también el disparador que me hizo querer esribir sobre el nivel de madurez que debe tener una Organización para poder trabajar bien el mundo COBIT. Hasta ahora, siempre he tocado COBIT como una herramienta de apoyo a la implantación de procesos desde el punto de vista de ITIL.. un simple "truco de magia" para dotar a ITIL de cosas que no tiene, pero la realidad es al revés (al menos explicitamente por parte de COBIT, la cosa es al revés): COBIT reconoce abiertamente estar muy centrado en el qué, y deja el cómo a otros estandares, metodologías o marcos de trabajo que estén centrados en el área operativa; por esta razón es por la que hay documentación de ISACA para mapear COBIT con ITIL, ISO27000, CMM o incluso PMBOK.

Pero ahora pensemos en los primeros pasos de COBIT: se habla de alinear IT con el Negocio mediante el aseguramiento de que la información cumple con los requerimientos de negocio (los 7 famosos requisitos de la información) y de cómo se produce una "cascada" de información desde los objetivos de negocio hasta las propias personas, tal y como se ve en la gráfica

Así, modelaremos los recursos IT y los procesos IT en función de los requerimientos de negocio, y esto es una alineación de las TIC con el negocio enfocada de arriba a abajo, y no de abajo a arriba que es como se suele explicar en el mundo ITIL.

Ah! y esto? en qué nos afecta?

Pues.... la respuesta a la pregunta te la darás tú mismo: ¿Cuáles son los objetivos de negocio de la Organización en la que trabajas? Si los conoces, entonces tienes el punto de partida y puedes hacer el trabajo de alineación.

Pero si no los conoces... si resulta que tu organización no transmite claramente los objetivos de negocio (o si simplemente no los tiene detallados, que no sería la primera) entonces cabe preguntarse: ¿Cuántos objetivos tiene la compañía? Casi que unos cuantos por directivo, unos cuantos por mando intermedio y unos cuantos por trabajador; es decir, cada uno se plantea sus propios objetivos, y así ¿Quién se alinea con quién?

(Aquí vuelve a aparecer nuestro mando intermedio de una de las áreas de ventas, que al margen de los objetivos que pueda tener la empresa con respecto a su departamento y a las funcionas que desempeña la gente que esté a su cargo, tiene unos objetivos personales claramente definidos y por los que está dispuesto incluso a falsear informes para no aparecer mal en la foto)

Por lo tanto, necesitamos que antes de pensar en aplicar COBIT como framework para el Gobierno de las TIC (una de sus varias utilidades, pero quizás la más importante y en la que estaban pensando cuando lo hicieron) los primeros pasos en Gobierno Corporativo (si no formalmente, al menos informalmente) se hayan dado, y la compañía tenga definidos claramente los objetivos de negocio a los que nos debemos alinear.

PD:Un par de definiciones:

Gobierno Empresarial

Es el conjunto de prácticas y responsabilidades ejercidas por la Dirección Ejecutiva con la meta de proporcionar dirección estratégica, asegurándose de que los objetivos son cumplidos, comprobando que los riesgos se gestionan adecuadamente y verificando que los recursos de la Organización se utilizan adecuadamente

de esta definición vemos que el Gobierno Empresarial es a la Organización lo que el Gobierno de las TIC es a la Organización TIC.

El Gobierno de las TIC es responsabilidad tanto de la dirección como de la administración ejecutiva. No es una disciplina aislada, sino que es parte integral del Gobierno Empresarial (o Corporativo) y consiste en el liderazgo, las estructuras organizativas y los procesos necesarios para asegurar que las TIC mantengan y amplíen los objetivos y estrategias de la empresa

Claro, y en definitiva, si pretendo que "las TIC mantengan y amplíen los objetivos y estrategias de la empresa", como la empresa no los tenga definidos no llegaremos a ningun buen resultado.