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: cobit, itil, gobernotic

del.icio.us tags: cobit, itil, gobiernotic

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.

Buscando Foro para GobiernoTIC

A la vista del comentario de Mr. K en el anterior post, y también un poco porque me muero de envidia de ver la funcionalidad de notificación de nuevos comentarios que tiene montado Mr. Skeptic, busco hospedaje gratis para foro asociado al blog GobiernoTIC.

¿Alquien me recomienda algún servicio de hospedaje de foros en particular? A ser posible gratis, que esto del Google AdSense no da para mucho!!

Gracias!

ACTUALIZACION:

Ops! Hoy me he dado cuenta de que había algún tipo de problema con la encuesta.Al parecer ahora ya está corregido y se puede votar.

¿Cuánto cuesta un servicio?

Aeropuerto de Madrid, sala VIP de Spanair y 3 horas de espera antes del embarque. Después de mirar el correo y leerme los posts pendientes del blogroll (y de flipar con la escasa seguridad del web-kiosk de esta gente!) me planteo pasar el rato escribiendo un post que me lleva rondando la cabeza unos meses.

Acabo de terminar uno de esos cursos de ITIL que había mencionado en un post anterior, y cuando estaba explicando el apartado de Gestión Financiera, iba tomando nota mental de cosillas que quería aclarar(me) al escribir esto.

Tal y como explican detalladamente en el Service Delivery, la Gestión Financiera tiene 3 grandes patas: la realización de presupuestos, la contabilidad de costes y la repercusión posterior de estos costes. Como la clave de todo está en la contabilidad y como, además, da igual si quieres facturar o no porque la contabilidad te da información económica importante a la hora de tomar decisiones, este es uno de los puntos en los que más enfatizo al explicar esta parte en los cursos.

La problemática especial que nos vamos a encontrar en la contabilidad de costes no es saber el coste acumulado, el "total" del dinero gastado, sino que el problema realmente dificil de superar es el conseguir una contabilidad analítica que tenga la suficiente capacidad como para llegar a decirnos cual ha sido el coste de provisión de un determinado servicio.

¿Cuánto cuesta la e-tienda? ¿Cuánto cuesta el proceso de facturación? ¿Cuánto cuesta algo tan simple como el correo electrónico? Pocos departamentos de IT Pueden responder a esta pregunta, y sin embargo es vital para tomar decisiones económicas al respecto tales como ¿vale la pena externalizarlo? ¿vale la pena mantenerlo? ¿vale la pena que lo actualicemos o que cambiemos la plataforma?

Ya se que estas decisiones no dependen únicamente del coste del servicio, pero es necesario tener el coste en consideración a la hora de tomar las decisiones.

Ahora que ya sabemos por qué es importante contar con la contabilidad de costes de la provisión de servicios, veamos un poco cómo podemos hacerlo. En esto sí que tienen experiencia las organizaciones: todas tienen un departamento de contabilidad, así que en ese departamento tendremos un aliado importante.

¿Debemos montar una contabilidad paralela, o "externalizar" este servicio hacia este departamento de contabilidad y finanzas? Esta es una buena pregunta que debe ser respondida, no desde el corazón, sino desde la neurona y el sentido común: a priori y con ese afán de "Juan Palomo, yo me lo guiso, yo me lo como" la gran mayoría de los directores de IT querrán llevar su proia contabilidad adecuada a sus necesidades concretas, pero siendo sinceros y prácticos ¿cuántos departamentos de IT tienen los conocimientos ,la práctica y las herramientas necesarias para hacerlo? Para mí está claro que cada uno debe hacer lo que sabe hacer y, de la misma forma que la contratación de personal la realiza RRHH con ayuda de IT y bajo petición de IT, la contabilidad la debe llevar Contabilidad y Finanzas (CyF) con ayuda de IT y bajo petición de IT (¿o acaso a nosotros nos gustaría que CyF se fabricara un CPD y guardara en él sus sistemas y montara su propio ERP y etc, etc? La empresa es un conjunto de cajas que hacen de cliente y de proveedor entre ellas).

El algoritmo simplificado para calcular el coste de un servicio viene a ser algo así como

1. Detecta y clasifica las Unidades de Coste (Cost Unit) (ITIL proporciona una guía con 6 unidade se coste)
2. Analiza para cada Unidad de Coste los elementos de coste que la componen
3. Separa estos costes entre directos e indirectos. Imputa los directos directamente (como su nombre indica) y establece un criterio de reparto para los costes indirectos, aplicándolo en consecuencia.
4. Decide qué costes se van a imputar completamente en el ejercicio (Costes Operativos) y cuáles se van a imputar en años sucesivos, como una amortización (Costes de Capital). Para los costes de capital incluye el coste anualizado.

¡Fantástico! Hasta aquí parece fácil, pero una de las trampas importantes de este discurso es el punto 1: no hemos hablado de cuales son las Unidades de Coste (las fuentes u orígenes de los costes en sí). Si rascamos un poco más, veremos que las UC propuestas son las siguientes:

1. Unidad de Coste de Equipamiento (ECU) -- todo el hardware
2. Unidad de Coste de Software (SCU) -- Costes directos e indirectos de Software (SO, BBDD, Gestion, Aplicaciones)
3. Unidad de Costes de Organización (OCU) -- Costes directos e indirectos de personal (sueldos, formación, viajes)
4. Unidad de Costes de Instalaciones (ACU) -- Costes directos e indirectos relacionados con las instalaciones (CPD, oficinas, etc)
5. Unidad de Costes de Transferencia (TCU) -- Cargos internos entre departamentos.
6. Costes Contables (AC) -- Costes asociados a la gestión financiera.

Y de esta forma se han destapado un par de huesos duros de roer: la Unidad de Costes de Organización y la Unidad de Costes de Instalaciones:

La OCU nos pide no sólo que tengamos el total de costes de personas (cosa relativamente sencilla si la pedimos en RRHH) sino que nos pide que sepamos cómo repercutir los costes de personal por servicio (estableciendo el criterio de reparto de los costes indirectos).

La ACU nos pide que seamos capaces de repercutir tambien por servicio costes de instalaciones (el consumo eléctrico, el coste del aire acondicionado, el m2 de suelo del CPD, etc.)

Para resolver el primero de los planteamientos, necesitaremos realizar un seguimiento del "consumo de horas/hombre" por cada servicio, para lo que se hace imprescindible la utilización de herramientas de reporting de horas, ya sean hechas en casa o compradas.

Para resolver la segunda problemática necesitamos o bien llegar a un nivel de detalle que no acabará siendo rentable o bien simplificar al extremo: costes de instalaciones dividido entre servicios y a cada servicio su parte proporcional, ya que podemos interpretar las instalaciones como un "Servicio General" que se debe subvencionar entre todos los servicios.

Bueno, hasta aquí la parte de contabilidad pero han quedado varios puntos abiertos que deberían ser foco de otras reflexiones: los criterios de reparto de los costes indirectos entre los diferentes servicios, las técnicas para la imputación de horas a los diferentes servicios o las técnicas para repercutir aunque sólo sea con carácter informativo estos costes sobre las diferentes organizaciones cliente.

Postdata: al final el vuelo resulto ser un caos total, primero el avión se retrasó en llegar a Madrid 1 hora ,después hubo que limpiarlo y cargar las maletas, después detectaron una avería técnica en el avión, así que nos cambiaron de aparato, luego hubo que cambiarlo todo de sitió, para continuar, anunciaron congestión en el espacio aéreo de Madrid y, cuando al fin estabamos para despegar, resulta que el capitán anuncia por megafonia que han cambiado la configuración de despegue y que tenemos que esperar un rato más... en total, más de 8 horas para llegar desde Madrid hasta Barcelona... son cosas que pasan, pero cada vez más frecuentemente en los vuelos MAD - BCN de los viernes.

¿Formalizar o improvisar?

A la vuelta de vacaciones me he encontrado con una gran cantidad de artículos que leer, sobre todo en los blogs sobre ITSM que frecuento. Veo que el verano ha sido fructuoso para todos y me encuentro una gran variedad de temas y opiniones, pero me han llamado la atención los de Charlie Beltz en erp4it y los del IT Skeptic.

Cuando leí el mensaje de Charlie a Mr. Skeptic me dió por pensar que Charlie no comprendía exactamente lo que Mr Skeptic estaba diciendo al respecto de si la CMDB es "una cosa" o "un sistema"... en definitiva, lo que defiende el escéptico no es más que la pureza de las palabras y lo que defiende Charlie es una ampliación de conceptos y una evolución/maduración de los conceptos:

Cuando el Mr. Skeptic dice

CMDB is NOT “a landscape … a system” or a “political-cultural process”. Bullshit. I’m not sure whether this reflects the author’s ignorance of ITIL or blatant lack of respect for the meaning of terms, but either way: stop it!. Invent your own bloody terms and leave CMDB alone.

lo que está defendiendo es que no reinventemos o adaptemos el significado del término CMDB y que si necesitamos añadir un concepto más al ya amplio glosario de términos de ITSM simplemente lo hagamos (¡y más con la facilidad que tienen los angloparlantes para inventarse las palabras!), mientras que cuando Charlie dice

In fact, what is needed is an enterprise architecture for IT - one in which a specific CMDB may be central, but only as first among equals in an overall ecosystem of tools to manage the IT value chain.

lo que está defendiendo es precisamente que el concepto de CMDB tal y como lo definen los libros (actuales) de ITIL se le queda corto.

Y entonces leí uno de los fantásticos "food for toughs" de Charlie que decía

Second food for thought:

• The Service Catalog contains Service Offerings.
• The CMDB contains Service Instances.

y se me iluminó la ampolleta en mi cabeza: ¿cómo puede ser que todo un veterano como Charlie tenga alguna duda al respecto de la relación entre los servicios y la CMDB?

Muy fácil: porque no está definido estrictamente (formalmente) en ningún sitio, y ese es el punto crítico al que se está llegando últimamente en las discusiones de los foros... Si nos fijamos en los estilos de los diferentes discursos de los autores o generadores de opinión en este mundillo, hay principalmente 3 estilos:

• El estilo universitario: trata de formalizar y de describir sin lugar a dudas el concepto que quiere explicar, totalmente científico y amante de cosas como el DCML, el UML y otros *ML de su colección. No está muy cercano al mundo real, pero es ciencia de base.. definen los conceptos que tarde o temprano acabaremos utilizando todos. De este estilo es el blog de Charlie o (saliendonos del mundillo ITIL) las explicaciones ontológicas de Jorge Fernandez.
• El estilo estricto: lo que hay escrito va a misa, y por lo tanto no nos debemos desviar demasiado del "dogma". Ya sabemos que hay muchos que viven todo esto como si de una religión se tratara y cambiar las bases de este tipo de pensamiento siempre es difícil.
• El estilo campechano: con una visión ecléctica y práctica de la vida, no se casan definitivamente con ninguno de los conceptos ni estándares y utilizan en cada momento el que más apropiado les parece y si es necesario variarlo un poco, pues no pasa nada. ¿Que lo que estamos hablando no es exactamente una CMDB, pero es lo que nos apaña en este momento?, ¡pues no pasa nada!

Como pueden imaginarse, las famosas Best Practices son más del estilo campechano que del estilo universitario, pero el mercado está empezando a reclamar más formalidad (desde el punto de una descripción formal de los conceptos) para que nadie tenga dudas de si lo suyo es que en el catálogo de servicios haya ofertas o estén definidas cada una de las instancias de los servicios ¿o esto debería estar en los ANS?

Con una situación como la que tenemos ahora, es bien dificil pensar en reailzar un benchmarking entre compañías o en comparar el análisis de madurez de procesos (assessment) de una con la otra.

Ahora bien... con la entrada de la ISO20000 en juego, me juego a que todo esto va a cambiar.

Permanezcan atentos a lo que se avecina, u opinen libremebte sobre lo que han leido.

La vuelta al cole

Bienvenidos!

Bueno, ya he vuelto de esas deseadas vacaciones. He descansado, he desconectado y me he dedicado a los otros hobbies que me permiten no pensar en informática todo el rato. Esto ha hecho que haya vuelto un poco "escéptico" y tardaré un par de semanas más (al menos) en volver a coger el asunto con la ilusión, alegría y pasión que normalmente me caracteriza.

Pero vamos a la materia: el punto central que me ha llevado a escribir este post es que Septiembre es el mes de la Vuelta al Cole. Los niños, ilusionados, estrenan libretas nuevas y ven en los libros la promesa de todo lo que van a aprender en el nuevo curso; los mayores, no tan ilusionados, volvemos al trabajo con nuevos proyectos, pensamientos o desesperaciones y los clientes llaman a las puertas de los proveedores con un montón de ideas nuevas.

Y para mí ha resultado ser realmente la vuelta al cole: me esperan por lo menos 4 cursos de ITIL, un par de ellos de COBIT y no se qué más sorpresas me tienen reservadas los comerciales.

Uno de los clientes que van a recibir formación me mandó un mail esta semana, comentando que quiere comenzar a preparar planificaciones y presupuestos para el 2007 y quería información al respecto de la formación específica sobre ITIL Practitioner y Manager. (¡¡Hola Eduard si me estás leyendo!!)

Supongo que la problemática que se le plantea a este señor se le planteará a más de una persona durante los próximos 6 meses y por eso me parece un tema interesante sobre el que reflexionar: "Cual debe ser el comportamiento de los clientes (usuarios de ITIL) con respecto a las actividades formativas y sobre todo las de certificación de cara al 2007?"

A primera vista la respuesta debería ser simple: haz lo que debas. Pero... si añadimos a la coctelera dos ingredientes ligeramente picantes, veremos como el coctel sale con un gusto completamente diferente:

1.-El proyecto de refresco de ITIL promete que tendremos las primeras publicaciones a finales del 2006 o principios de 2007, por lo que este mundillo va a sufrir la revolución de pasar de un esquema de trabajo orientado a procesos a un esquema de trabajo que, en el núcleo tiene el paquete de procesos pero que se ve ampliado en sobremanera con la visión de Ciclo de Vida del Servicio.

¿Significa esto que lo que ya sabemos de ITIL no vale y los cursos que hemos hecho se han quedado obsoletos? En absoluto! Ahora bien, hay nuevas cosas que estudiar, nuevas cosas que aprender, nuevos conceptos que aplicar y nuevas piezas del puzle que encajar...así que todo requiere un pelín más de trabajo.

De la misma forma que COBIT 4 ha ampliado los conceptos de COBIT 3, pero a la vez lo ha hecho bastante más fácil de entender y de aplicar, espero que ITIL V3 potencie y facilite la comprensión de ITIL V.2

2.- El proyecto CAR avanza, y en ese avance ya se han firmado los acuerdos con APMG para que tome la responsabilidad de los nuevos esquemas de certificación basados en ITIL V3 a partir de mediados del 2007, por lo que tanto ISEB como EXIN pierden esta parcela de negocio y las empresas asociadas a ellos deben estar ya moviendose para conseguir los nuevos acuerdos con APMG.

En definitiva, que el 2007 será un mal año para conseguir certificaciones basadas en V.3 porque los temarios serán nuevos, los profesores sólo podremos explicar de forma teórica los contenidos porque no se tendrán experiencias reales de implantación de los nuevos componentes del modelo, las compañías de formación posiblemente no tendran ligados los contratos con APMG y además quién sabe qué modelo de negocio piensa aplicar APMG a todo esto (porque quitar de enmedio a ISEB y EXIN les debe haber costado lo suyo y ahora querrán recuperarlo, como es normal).

Así que plantéate exactamente para qué quieres certificarte tú o certificar a tu gente. Yo siempre digo que hay tres motivaciones diferentes para la certificación:

1. Las certificación de Marketing: Para vender mi currículum, para vender mis servicios o para que mi compañia pueda vender más y mejor necesito que aparezcan toda una serie de certificaciones en él, así que me las saco y punto. Aquí el objetivo es conseguir el papelote con el certificado lo antes posible, así que valen todas las tretas habidas y por haber (o nadie ha usado un brain dump nunca?)
   
2. Las certificaciones por Amor Propio: me gusta cómo brilla el pin de Service Manager en mi solapa, así que me saco la certificación y a todos los eventos que puedo voy orondo y redondo con mi flamante certificado. Mola casi tanto como la de LPI nivel 3 o la del CISA, CISM, CISP y no se qué mas CIS que tengo...Aquí valen los trucos para aprobar el examen, pero tambien hay que saber un poco de qué se está hablando: si vamos a fardar de certificado como mínimo que sepamos qué significan sus siglas, no? (se han fijado que en las publicaciones de ISACA siempre aparecen los nombres seguidos de la ristra de certificados? A mi me mandan las cartas a nombre de Antonio Valle, CISA)
   
3. Las certificaciones como Reconocimiento del Conocimiento:voy a participar en un proyecto en el que hay toda una serie de conceptos que no conozco, así que recibo la formación necesaria y me certifico para demostrarle a mi empresa que he atendido en las clases y estoy capacitado para participar en el proyecto.Aqui lo que realmente importa es que hayas aprendido, hayas estudiado y sepas de qué va el asunto; el certificado es un efecto colateral sin importancia.
   

De todas estas, la que más me gusta es la 3... aprender aprender y aprender y si hay o no un certificado, da igual. Así que de cara al 2007 recomiendo esto... lecturas obligadas para todo el mundo, estudio y ya nos certificaremos más adelante, cuando el río baje más tranquilo.

ACTUALIZACION

Hoy se ha publicado una nueva nota al respecto del proyecto CAR relativa directamente a las certificaciones... no tiene pérdida

http://www.itsmf.com/news/news.asp?NewsID=243

así como no tiene pérdida la rápida respuesta dada desde el ITSM Portal

http://en.itsmportal.net/en/node/14206