Búsqueda


31 de diciembre de 2007

El último del año

bola Bueno, se acaba el 2007 y es hora de hacer un poco de recapitulación. Después del sprint de final de año y pensando en el Enero que me espera, en el que poco podré escribir, lo único que puedo hacer es cumplir con el compromiso adquirido en Diciembre del 2006 y revisar el resultado de las predicciones hechas.

1.- Agregación empresarial: El 2007 fue, efectivamente, un año de compras. Fue especialmente intenso en el área de BI, donde sólo queda Microstrategy por ser comprada (la última opción de HP?); también hubo compras en el mundo de la gestión de tecnologías y CMDB: las grandes van cerrando filas en torno al concepto de FCMDB

2.- ITIL V3: Efectivamente fue el año de su lanzamiento. Por ahora, y en mi opinión, mucho ruido y pocas nueces, pero veremos los primeros casos de estudio (mucho marketing y poco contenido, esa es mi predicción) en el 2008,

3.- CMMI para servicios: El gran fracaso de la Carnegie para este año 2007 fue el hecho de que los sponsores de CMMI-SVC detuviesen el proyecto justo cuando estaba a punto de ser lanzado. A finales del 2007 lo han vuelto a activar, así que espero que en el 2008 lo podamos ver "en la calle".

4.- IT Governance Association: Yo les he perdido completamente la pista, no se si han hecho algo este año o simplemente fue un poco de humo para empezar el 2007 con ruido. ¿Alguien sabe algo?

5.- Cobit 4.1: Efectivamente, el 2007 ha sido el año de las publicaciones alrededor del mundo COBIT, y ha entrado con mucha fuerza en el mercado español. Ahora ya muchas compañías ofrecen servicios y formación alrededor COBIT, a pesar de que no son demasiadas las referencias de utilización real. Creo que tendremos muchas más novedades en el 2008 a este respecto.

6.- itSMF Benchmark: Efectivamente, han ido trabajando y publicando resultados durante el año 2007, pero no con la fuerza que yo me esperaba. Es un sector realmente importante y en el que seguro que hay mercado.

7.- Guerra en el mercado de la formación: Efectivamente, ha habido "movida" en el mercado de la formación y la certificación, pero las grandes han preferido hacer las paces y aliarse antes que hacer demasiado ruido.  Veremos qué tal entrada tiene la nueva certificación de ISACA en este mundillo.

8.- Las patentes de software: silencio absoluto a este respecto. No se ha movido nada y sin embargo estoy seguro de que las grandes (IBM, MS, HP,etc..) no han parado de patentar más y más ideas de "ciencia base".

9.- Actividad en el mundo ISO 20K: Efectivamente, se anunciaron las primeras empresas certificadas en este ámbito, se han ofrecido toneladas de cursos y muchos son los que ya han empezado a prepararse para la obtención de los certificados. Además, se publicaron las normas oficiales en castellano y catalán.

Bueno, han sido seis aciertos de nueve... aprobado como "predictor del futuro". 

Y para el 2008, qué? Pues me tiro a la piscina y hago mi quiniela particular:

1.- Entrada de Microsoft en el mundo de la gestión de procesos: presentarán su herramienta System Center Service Manager y se convertirán en un serio competidor para las otras empresas "acomodadas" en el sector.

2.- Seguirán las compras: HP, IBM, Oracle, SAP, Google, EMC... seguirán comprando a medianas empresas y continuarán engrosando sus tamaños. ¿Comprará HP a Symantec? ¿Microsoft a SAP?

3.- Entrada en España de empresas de UK? (esta es más difícil, pero... ) ¿Se decidirán por el mercado español empresas como Pink Elephant o Partners in IT?

4.- Los catálogos de servicios serán el producto estrella: hace unos años, los proyectos de implantación de ITIL empezaban o bien por la racionalización del helpdesk o bien por la construcción de una CMDB a partir de herramientas de inventario. Creo firmemente que eso cambiará y que durante el 2008 lo que se venderá será la creación de un catálogo de servicios como punto de inicio (evidentemente, esto da para mucho más que una predicción, pero es lo que hay).

5.- El tema de estudio: El control de los procesos externalizados. Se hablará y mucho durante el 2008 sobre qué hacer con aquellos procesos que están externalizados en parcial o totalmente a uno o varios proveedores externos. Empezaremos aquí mismo con una votación que colgaré en la barra derecha del blog.

6.- Cuadros de mando, donde BI e ITSM convergen. Veremos actividad en este sector, donde se puede dar mucho valor a un proyecto y diferenciarse de la competencia.

7.- Y por último: ¿Podré escribir mi libro? Me encantaría, pero no doy demasiado por ello... ya veremos qué ha ocurrido en Diciembre de 2008.

Pues hasta aquí con las predicciones para el 2008.

FELIZ ENTRADA DE AÑO

Y recuerda para el año que viene:

Una buena flecha no hace a un cazador. Se necesita algo más que una buena herramienta.

¡¡Buena Caza!!

5 de diciembre de 2007

No los he abandonado

Hace días ya que no escribo, y hoy me he dado cuenta de que quizás debía dar al menos señales de vida para que nadie se vaya a pensar que he abandonado el mundillo y me he ido a criar cabras al campo, o que les he puesto los cuernos definitivamente y me he puesto a escribir de forma anónima para una revista.

No. No es nada de eso... simplemente es que el trabajo se me come: estoy inmerso en un par de proyectos que me consumen tanto tiempo y esfuerzo mental que sinceramente no me quedan ganas de escribir, ¡ni siquiera de tirar fotografías!

Pero durante este tiempo de duro trabajo, aprendo. Aprendo del proyecto en sí, de la gente para y con quien trabajo, de proveedores, partners, compañeros... y todo eso alimenta ideas, comentarios y futuros artículos que irán llegando cuando, al fin, se terminen los proyectos.

Además, durante este tiempo han pasado muchas cosas: se ha hecho el congreso del itSMF (no pude ir, así que acepto cualquier artículo contribuido de quien quiera hacer una reseña de cómo fue!), ISACA ha sacado su nueva certificación profesional, la Carnegie ha retomado el proyecto CMMI-SVC (qué ganas tengo de escribir sobre esto, que para eso participé en el Review Team), Rosa García ha abierto su ventanal y es todo un espectáculo ver cómo intenta navegar en las aguas turbulentas en las que se ha metido, he participado en el QA Team de un nuevo libro de métricas por publicar, estoy en el equipo editor de un monográfico de la Novática que va a hacer historia...

Vamos, que cosas para explicar tengo, así que no pierdas la sintonía!

14 de noviembre de 2007

¿Qué tienes de ITIL V3?

Cuántas veces me han preguntado este año clientes, amigos, compañeros, la tan sabida pregunta: ¿Tienes algo de V3 que me pueda mirar?

A algunos se les puede pasar algo de documentación interna, a otros se les puede ofrecer una sesión formativa, y a otros se les puede echar una mano o dar algún enlace, pero siempre te queda el gusanillo de querer ayudar un poco más.

¿Qué tengo de la V3? Para empezar una suite de libros que son un tocho impresionante. Densos, y que necesitan no sólo de una lectura tranquila sino de una digestión reposada; sinceramente creo que tardaremos años en asimilar bien bien lo que significan esos cinco libros y no sólo por la magnitud de los contenidos, sino porque creo de verdad que están especialmente escritos así para ello: a veces me han dado ganas de coger uno sólo de los libros y expandir cada una de esas pequeñas frasecillas que tienen a su verdadero significado (o interpretación). El resultado sería "La Espasa del ITIL", en 100 cómodos tomos, o ... simplemente "Conocimiento Adquirido" dentro de 10 años.

Mientras tanto, y para echar una mano, ha venido el itSMF y nos ha echado un pequeño cable: han publicado la guía de bolsillo y, al igual que en el caso de ITIL V.2, la han hecho pública y descargable: una pequeña guía de unas 60 páginas que contiene lo mínimo que hay que saber sobre la V3 para poder decir que se sabe algo al respecto.

Buena Lectura y, sobre todo, buena digestión!

An Introductory Overview of ITIL V3

5 de noviembre de 2007

Outsourcing, Gobierno TI y Santo Tomás

Ya he comentado más de una vez en alguno de los artículos publicados por aquí que me llama la atención cómo las cosas nunca vienen solas. ¿Será que nos persigue un destino indescifrable?

Escribía hace cuatro días en GobTIC Flash sobre la importancia de COBIT en un entorno externalizado, hoy leía un artículo en la edición de Junio del IS Control Journal sobre la posibilidad (para mí remota) de externalizar la función de Gobierno TI y hoy me llega al buzón una pregunta para el Consultorio GobTIC con un texto como el que sigue:

[...] se está a punto de adjudicar una externalización total de los servicios del área de Sistemas. Pués bien, el viernes me propusieron que fuera el responsable del "gobierno" de los servicios y aquí me asaltarón dudas. ¿Por donde empiezo? ¿Establecemos métricas estilo COBIT para controlar posibles ANS (perdón SLA)? ¿Definimos un catálogo de servicios a prestar? ¿Acabamos de implantar la gestión de la configuración añadiendo, en lo posible, datos económicos no contemplados en su día? ¿A qué santo rezo? [...]

La Incredulidad de Santo Tomás

La respuesta a esta pregunta podría ocupar tomos y tomos, o bien se podría resumir en un simple "Rézale a Santo Tomás", patrón de las Universidades, la enseñanza y de los incrédulos.

Bromas aparte, vamos a ver unas cuantas cosillas que hay que tener en cuenta: lo primero es lo primero, así que si te proponen ser el responsable del gobierno de los servicios, tenemos que dejar claro qué significa Gobierno y qué significa Servicio en tu contexto. Me da la sensación que el término Gobierno en este contexto significa "Supervisión del desempeño del outsourcer", mientras que el término Servicio es más delicado, ya que me hablas de externalizar los servicios del área de Sistemas de una gran organización, luego el concepto Servicio IT posiblemente no sea el que aplique aquí.

Veamos tus reguntas una por una:

¿Establecemos métricas al estilo COBIT para controlar posibles ANS/SLAs?

Ojo con esto, ya que es un error muy común a la hora de pensar en métricas. Siempre que pensamos en métricas acabamos pensando en SLAs y casi se podría decir que no tiene nada que ver (ojo, ¡casi!). Las métricas pueden medir varias cosas, servicios, procesos, cumplimiento de objetivos, etc. COBIT plantea métricas que ayudan a medir procesos y actividades, pero nunca Servicios TI.

De esta forma, podrás establecer métricas de COBIT que te ayuden a definir los SLA de Proceso del proveedor (Resolución de Incidencias, Gestión de Cambios, etc...) pero COBIT no te dará métricas de Servicio TI (rendimiento de la Intranet hospedada y gestionada por el proveedor).

¿Definimos un Catálogo de Servicios a prestar?

¡Ya tardas! Si no existe este catálogo de servicios, la oferta del proveedor será una gran estimación y luego todo serán discusiones. Además, será sobre este catálogo de servicios sobre el que podrás negociar los SLA (la S es de Servicio, no lo olvidemos) y establecer esas métricas de servicio.

Es decir, tal y como me lo imagino, la oferta del proveedor sin catálogo de servicios se podrá comprometer a métricas de proceso (porque se siente que los puede controlar) y a catacterísticas genéricas de los sistemas, pero no puede llegar a comprometerse en métricas concretas de servicios porque no sabe cuáles son.

¿Acabamos de montar la Gestión de Configuraciones?

Oh! ¡Qué bonita pregunta! En el más puro sentido de la externalización, en el momento en que el proveedor tome el control, a tu organización "le importa tres pepinos la configuración"... eso sería lo que uno podría pensar si se creyera de verdad todas las grandes maravillas de la externalización, pero... si te lo crees nunca más cambiarás de proveedor porque te tendrá pillado por donde no te gusta, teniendo él todo el conocimiento relativo a la infraestructura y las relaciones entre componentes.

Osea, o te aseguras una devolución perfecta del servicio externalizado a la finalización del contrato, o mejor quédate con el conocimiento de la configuración.

¿A qué santo le rezo?

Lo dicho, a Santo Tomás.

Para mi, la actividad principal debe ser la de supervisión del desempeño del outsourcer, junto a la definición, supervisión y mejora de los modelos de relación entre las organizaciones. Es decir, no creo que sea suficiente monitorizar los SLAs y "apretarle las tuercas" al proveedor cuando no se cumplan algunos de los indicadores, sino que se debe realizar una acción continuada sobre la relación, los procesos y los requerimientos del negocio sobre los servicios TIC que tienes externalizados.

Para acabar, una recomendación sobre las métricas: centrate en las métricas que te sirvan para gobernar (valga la redundancia) los servicios y la relación con el proveedor y deja las métricas de operación para el proveedor: es su trabajo.

Por ejemplo, en un proceso de Gestión de Incidencias, es fácil ver la métrica de "tiempo de primer contacto" o la métrica de "porcentaje de resolución en primer nivel de soporte"... a ti, como cliente, ¿realmente te interesa ese tipo de métricas? Seguramente te interesará una métrica del tipo "% de incidencias resueltas dentro de plazo".  Cuando este indicador no funcione bien, será el proveedor quien tenga que investigar en el valor del "tiempo de primero contacto".

PD: Me preguntabas en tu mail si se debería tener en cuenta a la gente de procesos y metodologías para esta labor: ¡¡POR SUPUESTO QUE SI!! Además, seguro que podrán ayudar un mucho en la definicion de controles, auditorias, indicadores, políticas, etc.

4 de noviembre de 2007

El Síndrome de Moisés

Aquí tenemos el segundo de los artículos contribuidos. Esta vez, Willians Romero, desde Lima (Perú), envía este cuento corto con moraleja final.

El nacimiento de Moisés ocurrió en un momento en que el gobernante, del mayor imperio conocido en la historia, había ordenado que todos los niños varones, hijos de inmigrantes, debían usar un dispositivo GPS para que pudieran asistir a la escuela, de otra forma morirían ahogados en el río de la ignorancia. No se especifica la identidad del monarca, pero se cree que pudo ser Bushés II[1], aunque también se han sugerido otros gobernantes anteriores.

María esposa de José, dio a luz a un hijo varón y lo mantuvo escondido durante tres meses. Cuando no pudo mantenerlo oculto durante más tiempo, en lugar de entregarlo para que muriera ahogado literalmente, entre lágrimas lo puso en un carrito de compras del supermercado y lo dejó caer desde la rampa, que conducía al estacionamiento, cuando la hija del monarca pasaba frente a ella, sus guardaespaldas vieron que el carrito se le venía encima y lo detuvieron, creían que era un atentado, pero para su sorpresa descubrieron que era un bebé, la hija del monarca, que era tan bella como bondadosa rápidamente tomó una decisión y lo adoptó como su hijo, llamándolo "Moisés" (que significa "rescatado").

Según el mítico relato, la joven hermana de Moisés, Isabel que trabajaba para el outsourcing de limpieza del supermercado, observó la trayectoria del carrito de compras y luego preguntó a la hija del monarca si le gustaría que una buena mujer cuidara al bebé. Entonces María se hizo cargo del niño como niñera, y Moisés creció.

Cuando Moisés, se hizo adulto, ya graduado en TIC y con una certificación internacional en ITIL, la empresa en la que trabajaba, lo asignó como Junior Consultant en el Global Bank, por tal razón un día tuvo que observar cómo trabajaban sus compatriotas. Al ver que un greengo[2], maltrataba a uno de ellos, que era el supervisor de la Mesa de Ayuda, lo despidió en el acto y ocultó el hecho ante sus superiores, esperando que nadie estuviera dispuesto a revelar algo sobre el asunto. Al día siguiente, vio a dos de sus compatriotas peleando e intentó apaciguarlos. El que se había metido con su otro compatriota reprochó a Moisés el despido del greengo. Moisés supo así que sus superiores ya conocían el asunto y que el monarca probablemente estaría pensando también en despedirlo; por eso huyó.

Cuando se evalúa la gestión de los servicios TIC es imprescindible la objetividad y es recomendable tener todos los puntos de vista existentes:

1. Cliente

2. Usuario Final

3. Proveedor Interno

4. Proveedor Externo

Porque sino correremos el riesgo que nos afecte el síndrome de Moisés y sólo mirar las cosas según el único color del cristal que tengamos, es decir desde un enfoque tecnológico ignorando que el del negocio es el determinante.

Por lo tanto es necesario buscar la alineación entre el negocio y las TIC, debiendo estas últimas entregar valor a los usuarios finales, al cliente y al negocio.

----------------------------------

Artículo contribuido por

Willians Romero Cuadros

ITSM Senior Consultant

[1] Cualquier coincidencia con personas o hechos reales es sólo una casualidad

[2] Denominación de los nativos de ese país

3 de noviembre de 2007

Redes sociales y grupos de contactos

Poco a poco, con el paso del tiempo, el número de visitantes a este blog va aumentando. Pocos son los que comentan, siguiendo la teoría de Jacob Nielsen, pero muchos son los que cada vez que se publica un artículo se dejan caer por esta, su casa, y leen con avidez cualquier cosa que se haya publicado.

Pues he pensado que sería bueno que nos conocieramos, que supiéramos quién es quien en este mundillo; así que he creado un grupo en LinkedIn llamado GobTIC orientado a aglutinar a los profesionales (de habla hispana principalmente) relacionados con el mundo de la Gestión de Servicios TIC, el IT Governance y, en general, la dirección de organizaciones TI en todos los ámbitos.

gobtic_linked_100x50

Puedes inscribirte en el grupo simplemente siguiendo este enlace:

http://www.linkedin.com/e/gis/40337/753D632338E9

Los grupos de LinkedIn sólo sirven para permitir los contactos entre sus miembros, no disponen de foros ni nada por el estilo; pero creo que es un primer paso. Cuando vea que realmente hay demanda, ya montaré un foro o páginas especiales para esta pequeña e incipiente comunidad.

Por lo pronto, los servicios ofrecidos desde Gobierno de las TIC son los siguientes (por orden de aparición):

1.- Consultorio GobTIC: sólo tienes que enviarme un mail o dejar un comentario con una consulta que quieras realizar y, si está a mi alcance y tengo tiempo, tendrás una respuesta en forma de post.

2.- Artículos Contribuidos: ¿Tienes un artículo que te gustaría publicar en Gobierno de las TIC? Pásamelo por mail y lo comentamos, si cuadra con el espíritu del blog se publicará (con las referencias oportunas, por supuesto!)

3.- Biblioteca GobTIC: Una selección de los libros más importantes en el sector, con secciones como "Recomendados", "ITIL" o "ISO 20.000". No todos los libros que aparecen en la biblioteca me los he leido personalmente, pero sí todos los que aparecen en la sección Recomendados. Está basado en la tecnología aStore de Amazon y puedes comprar directamente los libros ahí.

4.- Motor de Búsqueda:Un motor de búsqueda personalizado en Google orientado específicamente a los contenidos que más te interesan (ITIL, COBIT, CMMI, Six Sigma, IT Governance, ITSM, etc etc etc)

5.- GobTIC Flash: En el lateral derecho del blog encontrarás la sección GobTIC Flash, donde se publican mensajes cortos como puedan ser recomendaciones de enlaces, ideas, comentarios rápidos, etc. Está basado en la tecnología Twitter y puedes consultar todo el historial de mensajes aqui.

6.- Red social: El grupo LinkedIn GobTIC te permitirá entrar en contacto con otros profesionales del sector que, como tú, se dedican a este mundillo.

En el futuro quizás veamos un foro público y posiblemente una versión colaborativa de GobTIC Flash, ya veremos :-)

17 de octubre de 2007

Definiendo Servicios: mejor desde la ignorancia

LLega un momento en cualquier implantación/definición de procesos de Gestión de Servicios en el que, axiomáticamente, hay que definir los servicios. Hay compañias que empiezan la casa construyendo un catálogo de servicios bien detallado, hay otras que comienzan definiendo procesos y herramientas y al ir a pensar en los datos necesarios para la herramienta aparece el campo "Servicio" que hay que rellenar con algo, así que al menos hay que obtener la lista de servicios.

Sea como sea, cuando llega el momento de pensar en la lista de servicios invariablemente aparece la necesidad de definir el concepto servicio después vienen las discusiones al respecto de cuáles son los servicios que prestamos al resto de la organización (el negocio como lo llamamos habitualmente).

Bueno, vamos a empezar por una definición de servicio que estoy utilizando últimamente y que me cuadra bastante:

SERVICIO TIC:

Uno o más Sistemas TIC [...] proporcionados por el Departamento de IT y que facilitan los procesos de negocio de la Organización. Un Servicio TIC debe ser percibido por el cliente como una entidad coherente o como un producto consumible.

Lo que más me gusta de esta definición es aquello de debe ser percibido como una entidad coherente o como un producto consumible. Y aquí es donde viene la segunda parte del título del artículo: mejor desde la ignorancia.  Esa percepción a la que nos referimos, es la percepción del usuario, no la nuestra desde dentro de IT.

Escribo este post en un avión, volando desde Bruselas a Barcelona y precisamente lo que me ha inspirado el sentido de ignorancia es que yo no tengo ni idea de qué es lo que hace falta para conseguir que el avión me lleve desde un sitio a otro, los mecanismos, las capacidades, la atención del personal de cabina, etc... yo tengo claramente la percepción de vuelo y veo claramente que hay diferencias entre volar en una compañia Low-Cost o volar en Iberia Business Class... veo los diferentes niveles de servicio, pero no sé (ni quiero saber) las tripas que componen este servicio.

Cuando llega el momento de definir la lista de servicios que ofrece IT al negocio, mejor hacerlo desde la ignorancia (en el buen sentido de la palabra): vayámonos al negocio y preguntémosle qué es lo que ellos perciben como un producto consumible, qué es lo que ellos usan/piden/consumen de IT y tendremos gran cantidad del trabajo hecho y de discusiones internas eliminadas; porque nosotros, como IT ,conocemos las tripas del servicio y nos plantearemos dudas complejas sobre la estructura de servicios.

Un ejemplo simple: un servicio puede ser "el teléfono móvil". Si lo veo como usuario, es un aparato que sirve para llamar por teléfono desde cualquier punto del pais, con posibles ampliaciones al extrangero. Si lo veo como un entendido en la materia puede ser que decida diferenciar entre el servicio "teléfono móvil 3G", "teléfono móvil UMTS", "teléfono móvil satelital", porque, desde el punto de vista de IT son cosas diferentes.

Pero el usuario ni ve ni comprende estas diferencias... sólo quiere llamar por teléfono. (o sólo quiere volar... da igual el resto)

Se positivamente que este post me va a traer problemas, porque yo mismo he defendido en más de una vez que el correo POP es diferente servicio que el correo WEB o que el correo BlackBerry basándome en que a)los parámetros de medición son diferentes, b)los niveles de servicio son diferentes c)las infraestructuras/tecnologías que hay debajo son diferentes.

Pero en el fondo, el usuario sólo quiere leer el correo... lo que varía es cómo lo lee.

No pretendo sentar cátedra en este tema... sólo reflexiono en voz alta porque ninguna de las dos aproximaciones me da respuesta a todas las preguntas. Pero... desde la ignorancia las cosas se ven de una manera mucho más simple.

15 de octubre de 2007

Aquí huele a futuro...

Charlie Betz ha sido elemento de inspiración de más de un artículo en este blog. Escribe un blog llamado erp4it desde hace años (2003), antes incluso de que yo conociera el propio concepto de blog, siempre suele dar en el clavo y es el autor del libro Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children

Recientemente ha escrito un artículo llamado BISM - you (probably) heard it here first. en el que habla de un concepto que me ha parecido interesantísimo: El BISM o Business Information Services Management. La idea es que el concepto de IT Services se va quedando lentamente obsoleto y comienza a aparecer el concepto de Business Information Services, lo que me parece de lo más correcto si pensamos en que lo que realmente consume el negocio de las TIC es la información y, además, esto alinea con el concepto de "Requerimientos de la Información" que ya planteaba COBIT desde los inicios.

Por si fuera poco, profesionalmente he podido ver cómo el contacto entre el mundo ITSM y el mundo BI cada año es más frecuente y más estrecho, lo que me lleva a pensar que este nuevo concepto no está del todo desencaminado.

Aqui huele a futuro, y yo no he sido... ha sido Charlie!

8 de octubre de 2007

El día que HP perdió la pelota

Lo había dicho Jorge Fernandez en su blog, que Business Objects estaba en venta. Y para mí, la mejor opción era que HP hiciera una jugada maestra colocándose en el sector del Business Intelligence, dando más ancho de banda a la posición de NeoView y además nutriera toda la parte de HP Software con unas herramientas de reporting, dashboard y cuadros de mando "de película".

Pero hoy BO ha publicado la noticia: el comprador es SAP (¡Quién lo iba a decir!).

sap_announcement

La verdad es que los chicos de Palo Alto cada día te sorprenden más.

5 de octubre de 2007

El Motor de Búsqueda Personalizado

Una de las grandes novedades que ha presentado Google últimamente ha sido la posibilidad de crear motores de búsqueda personalizados (CSE o Custom Search Engine). Utilizando este nuevo juguete, te puedes montar un motor de búsqueda tan potente como Google, pero focalizado a las áreas de interés que tú quieras.

Desde luego, esto a primera vista no parece demasiado interesante, pero a la que le des dos vueltas, verás lo útil que puede llegar a ser.

Para empezar, he montado un CSE orientado a los contenidos que se ven habitualmente en este site: ITIL, ITSM, IT Governance, y otros conceptos similares, de tal forma que si haces una búsqueda de Proyecto de Implantación en Google estándard, obtienes algo así como esto:

google_std

mientras que si buscas en la barra de búsquedas de Gobierno de las TIC (justo encima del primer post), los resultados son estos otros:

google_cse

Como puedes ver, los resultados están totalmente orientados a los contenidos habituales que te encuentras por aquí, lo que ahorra bastantes páginas de resultados poco afinados en una búsqueda habitual en Google.

La segunda característica interesante de estas CSE, es que se puede refinar la búsqueda según una serie de parámetros preestablecidos, que se encuentra justo en la parte superior de los resultados. De esta forma, si clickamos sobre el enlace de "Presentaciones" el resultado es aún más concreto:

google_refine 

de tal forma que todos los resultados obtenidos son presentaciones en formato PPT.

¿Qué más se puede pedir?

Pues sólamente que no tengas que venir hasta Gobierno de las TIC a buscar la barra de búsquedas, sino que la puedas integrar directamente en tu navegador.

Para poder atender a esta necesidad, tendrás que disponer de un navegador que soporte OpenSearch, como pueden ser FireFox 2.X o Internet Explorer 7 y utilizar el enlace que encontrarás justo en la barra de búsqueda, o aquí mismo
 

Al pulsar ese icono, se te preguntará si deseas agregar a GobTIC como motor de búsqueda y, en el momento de aceptar, ya podrás comenzar a utilizar las búsquedas directamente desde tu explorador, ya sea bajo Internet Explorer

IE7

o ya sea bajo Firefox 2.X

ffox

Por último, se pueden incorporar personas al equipo que se encarga de agregar entradas al buscador o de crear nuevos criterios de filtrado. Si quieres participar, sólo tienes que irte a la página principal del motor de búsquedas GobTIC e inscribirte.

 

4 de octubre de 2007

¿Cuánto le cobramos?

Kruschev Corrían los tiempos de la guerra fría y la Rusia de Kruschev estaba profundamente orgullosa de la central térmica que se había instalado en las afueras de Kiev. Era la central más moderna, más potente ymás efectiva de mundo y serviría para proveer de electricidad a las grandes fábricas que darían a la Gran Madre Rusia una clara ventaja en la carrera armamentística y espacial.

Ceñudos ingenieros trabajaban día y noche para optimizar el rendimiento de la central y cientos de camaradas trabajadores arrimaban el hombro para conseguir que la Gran Madre Rusia pudiera situarse en cabeza en esta carrera y poder demostrar a esos estúpidos capitalistas amerricanos que el poder del trabajo siempre puede superar el poder del dolar; pero de repente un día 26 de Septiembre se oyó un ruido gorgoteante, como si a la gran estación le hubiese dado una extraña faringitis metálica y estuviera presa de unos espasmos pulmonares: tosió tres veces, la tierra tembló debajo de las turbinas, se oyó un largo lamento que salía de las tuberías llenas de vapor y la central quedó inmersa en un silencio sepulcral.

Los camaradas se miraban unos a otros, sin saber que decir y los ingenieros miraban una y otra vez sus indicadores, relojes, goniómetros y otros aparatos de nombre indescifrable, cuando del fondo de un despacho salió el compañero Director de Fábrica y rugió por encima de todos:

-- ¿Que diablos ha pasado?

A lo que un ingeniero gafotas de pelo blanco y bata sucia contestó

-- No lo sabemos, camarada Director. Algo se ha roto en las turbinas de presión.

--¡Y qué estamos haciendo para que se arregle, camarrada Ingenierro?!

-- Hemos enviado al compañero fontanero, para que revise las tuberías.

Un fontanero estudioso de las tuberías de vapor salió corriendo tres plantas más abajo para intentar reparar la avería, pero pasaron dos horas y no encontraba la causa del problema, así que el camarrada Director rugió de nuevo llamando al Fontanero Jefe de Turno; este buscó y buscó, pero no fue capaz de dar con la avería.

En el despacho del Director el teléfono no paraba de sonar: desde todas las fábricas de cabezas SS-20, tanques y piezas para el Sputnik querían saber para cuánto tenían con la avería, pero nadie sabía dar una respuesta, y el nerviosismo del Dirrector llegó al límite cuando sonó el teléfono que le comunicaba directamente con la Sede del Partido en Kiev.

La noticia de la avería había llegado a oidos de Kruschev, quien no podía creer que no se pudiera arreglar esta avería, así que avisó que en tres días iría de visita personalmente a ver la central térmica y que quería que para esa fecha el incidente se hubiese arreglado.

Llamaron al Ingeniero Jefe, al Fontanero Mayor, a tres profesores de las más prestigiosas Universidades, a un Premio Nobel de Física y a los más importantes ingenieros, termodinámicos, aceristas y constructores de la Gran Madre Rusia, pero la central se obstinaba en permanecer en silencio sin revelar la causa de su muerte.

Tres días más tarde, un séquito de automóviles negros llegó a la puerta de la central, y el camarrada Directorrr, temblando, esperó a que Kruschev bajara de su vehículo. Lo saludó marcialmente y le dió la noticia:

-- Camarrada Kruschev, la central no responde.

-- ¡¡ perrrro cómo puede ser!!! Es la central más moderna del mundo!

Cabizbajo, con la voz temblando y muerto de miedo, el Director le dijo

-- Hay un ingeniero que quizás nos pueda resolver el tema, pero tiene un pequeño problema, camarada: vive en Texas.

-- ¡¡!! ¿UN INGENIERO DE TEXAS?? ¿Me estás diciendo que un asqueroso capitalista puede resolver el problema?

-- Bueno, dijo el Director, siempre nos queda saber que como no es posible que sea superior a toda nuestra ciencia e ingeniería junta, nos podremos reir un rato cuando no pueda resolverlo... le demostraremos que nuestra técnica es tan compleja que no podrá ni entenderla.

Cuarenta y ocho horas más tarde aterrizaba en el aeródromo de Kiev una avioneta que traía a un curioso personaje: alto, rubio, con blue-jeans, botas vaqueras y sombrero de ala ancha calado se bajó del avión John Smith, el fontanero mejor valorado de Texas.

Pidió que lo llevaran de inmediato a la central y cuando estuvo delante de las turbinas se las miró lentamente, en silencio, con calma. Siguió con la mirada las tuberías, escogió una de ellas y fue pasando la mano lentamente sobre ella mientras caminaba haciendo ruido en el suelo de acero con sus botas, hasta que de repente se paró, echó mano al bolsillo y sacó un pequeño martillo de asa dorada y cabeza de marfil.

Los ingenieros rusos lo miraban con cara de asombro, enfundados en sus batas blancas y con esas gafas de pasta negra que tan habituales eran en esa época. Pensaban que aquel ser venido del otro lado del mundo era un cantamañanas que estaba engañandolos, pues nada bueno podía venir del otro lado del Atlántico, pero no se atrevían ni a toser.

El silencio sepulcral lo llenaba todo. No se oía ni el más mínimo zumbido, cuando John Smith dió un pequeño golpe de martillo sobre un gran tornillo de acero que sujetaba una junta.

Un sonido metálico y agudo se elevó por encima de todos, se oyeron unos gorgoteos, tres toses, un gran lamento y un ronroneo suave se comenzó a oir en la Central: el grave problema de la Union Soviética se había resuelto con un suave golpe de martillo de marfil

Todos estallaron en aplausos, ¡hurras! y ¡vivas! se oían por todos lados y el compañero Director abrazó efusivamente al americano y le felicitó.

-- Dígame, Señor John Smith, cuánto tendremos que pagar por tan impresionante labor!

-- No se preocupe, Camarada... la cuenta la tengo ya preparada y es muy simple -- dijo mientras le tendía un papel doblado que llevaba en el bolsillo.

Mientras lo leía, la cara del Camarada Director iba cambiando de color, al rojo, al granate y después al blanco cadavérico.

-- ¿1.000.005 US$ por 5 minutos de trabajo? Pero usted se ha vuelto loco, camarada americano!

-- Bueno, se la voy a desglosar para que entienda usted correctamente los componentes de la factura

Y le entregó la factura desglosada, que ponía así:

DESCRIPCION PRECIO
   
Golpe de martillo, 5 minutos 5 US$
Saber qué tornillo golpear 1.000.000 US$
TOTAL 1.000.005 US$

 

Poner precio a los servicios profesionales no es tan fácil como calcular una tarifa horaria.

Este post va dedicado al amigo Tic616, autor del blog Tic & Tac y en respuesta a su artículo "¿Cuánto le cobramos?".

He pasado por esa situación y sólo tienes dos opciones: le pegas un sableo impresionante como el del camarada americano (al fin y al cabo, el trabajo lo vale, ¿no?) o te ganas un amigo para toda la vida regalandole el servicio y diciendo que "mira... hoy por ti y mañana por mi", pero no te quedes en la ridiculez de cobrar 500€ porque es lo que marca "la tarifa habitual".

 

1 de octubre de 2007

Consultorio GobTIC: Auditando la implantación de Sistemas ERP

erp Una vez más, un lector del blog plantea sus dudas, ya sea vía correo electrónico o ya sea escribiendo comentarios a alguna de las entradas. En esta ocasión, Ricardo Javier preguntaba:

Muy bueno tu blog, soy un lector asiduo y he recibido varias recomendaciones y me ha sido muy util al ir a los sitios que recomiendas para consultar mas a fondo los estandares ITIL y COBIT principalmente, pero ahora la pregunta que te hago es si en algún lugar habrá una guia para auditar la implantación de Sistemas ERP, sé que ISACA ha realizado algunos mapeos de COBIT con PMBOK,CMMI,ITIL, ISO17799 y que cubren algunos aspectos a considerar.
¿Alguna sugerencia?

La respuesta no es del todo simple, ya que el terreno de la implantación de ERP no es precisamente mi fuerte, pero quisiera recomendar desde aquí dos importantes fuentes de información.


Por una parte, tenemos ISACA, que publica habitualmente manuales específicos para la auditoría de entornos comunes y que ha publicado dos documentos relacionados:

The purpose of these audit plans and internal control questionnaires (ICQs) is to provide the audit, control and security professional with a methodology for evaluating the subject matter of the ISACA publication Security, Audit and Control Features Oracle® E-Business Suite: A Technical and Risk Management Guide, 2nd Edition.

This practical, how-to technical and risk management reference guide enables assurance, security and risk professionals (both IT and non-IT) to evaluate risks and controls in existing ERP implementations and facilitates the design and building of better practice controls into system upgrades and enhancements. The publication is based on SAP R/3 versions 4.6c and 4.7 and is the second edition of the globally demanded 2002 initial edition.

  • Por último, la lista completa de publicaciones de ISACA relativas a entornos específicos la puedes encontrar aquí.

Por otra parte, una fuente muy interesante de checklists y controles la página del IT Compliance Institut, que desarrolla una gran cantidad de documentación y que dispone de la sección "Auditor Answers", donde puedes encontrar el artículo Auditor Answers: Enterprise Resource Planning Audits.

27 de septiembre de 2007

Ligeras modificaciones

Hacia días que no escribía, pero hacía mucho más tiempo que no le dedicaba un ratillo al diseño del blog. Hoy he añadido una nueva funcionalidad, que permite contraer los artículos largos y de esa forma poder presentar en la página principal una mayor cantidad de artículos.


Create polls and vote for free. dPolls.com

Yo creo que facilita la lectura, pero desde luego eres tú quien debe decidirlo, así que he montado una pequeña encuesta: facilita la lectura esta nueva funcionalidad? Te molesta, en lugar de ayudarte?

¡Sólo te costará un click de ratón y yo sabré qué te parece!

28 de agosto de 2007

Cómo aprobar el ITIL Service Manager (III)

La etapa de estudio (bis)

En el artículo anterior hablamos de la etapa de estudio, pero entiendo que los consejos que daba son quizás demasiado genéricos. En este post voy a tratar de aterrizar un poco más al mundo terrenal para ver algunos aspectos prácticos relacionados con el tipo de preguntas que verás en el examen.

Para empezar, hay que tener en cuenta el caso de estudio. Durante los cursos vimos un par de empresas tipo (Pecunia y Graphical Machinery) como casos de estudio para los ejercicios a realizar durante las clases; luego, al final del segundo curso te darán el caso de estudio en el que se basarán algunas (bastantes) preguntas del examen. En mi caso fue una empresa llamada CTI, Compañía de Transporte Internacional, S.L., una empresa de transporte de mercancías y pasajeros por toda Europa.

Verás que en el caso de estudio aparecen descripciones organizativas de la compañía (departamentos, estructura de Dirección, etc), descripciones funcionales del área TI y algunas (pocas) descripciones técnicas de los sistemas que soportan los procesos de negocio de la empresa. Lo que más importa son las descripciones de los departamentos (quiénes son tus clientes), las descripciones de los procesos de negocio y las políticas de la compañía. Este apartado de políticas viene a ser un mini resumen de los puntos más importantes del Plan Estratégico de la empresa estudiada y, por lo tanto, todo lo que puedas justificar en el examen gracias a estas políticas mejor... estarás "alineando las TIC con el Negocio".

De esta manera, en CTI había, por ejemplo, un apartado de las políticas que decía:

Para poder obtener ventajas de estas oportunidades y también para poder reducir el problema en los niveles de utilización y tener entregas justo a tiempo (just-in-time), el Departamento de Estrategia y Políticas cree que la forma adecuada de avanzar es con el uso de las Tecnologías de la Información para cambiar los procesos de gestión de la empresa.

si te piden justificar la necesidad del proceso de Gestión de la Disponibilidad y tu utilizas, entre otros argumentos, el hecho de que la estrategia corporativa pasa por entregas Just-in-time, quedarás como un señor y te llevarás un par de puntillos.

...y para llevarte toda una buena colección de puntillos, nada mejor que entender claramente el proceso de corrección. En el libro que te han dado durante el curso, aparece al final un apartado que se llama "marking guidelines", estas guías de puntuación le indican al corrector cómo se debe puntuar y te indican a tí cómo debes escribir el examen para ganar el máximo de puntos.

Veamos un par de ejemplos: en una de las preguntas de Service Support te preguntan

¿Qué medidas puede adoptar una compañía para asegurar que la CMDB está actualizada? (10 puntos)

Aquí podríamos escribir un libro completo, pero se nos irían las 3 horas del exámen en una pregunta de sólo 10 puntos (sobre 100), así que veamos lo que dicen las "marking guidelines"

Se deberían incluir al menos las siguientes medidas:

  • Gestión de Cambios: todos los CIs deben ser sometidos al control de la Gestión de Cambios
  • Comprobaciones operativas: como aquellas realizadas por el personal de HelpDesk cuando se reporta un incidente (lo que yo llamo "Auditoría Contínua")
  • Comprobaciones procedimentadas: comprobaciones específicas que se han introducido en los procedimientos de tal forma que cualquier modificacion queda registrada.
  • Auditorías Regulares
  • Uso de herramientas de descubrimiento que permitan detectar cualquier cambio no autorizado tan pronto como se realice.
  • Automatización de algunas actividades.

Se sugiere otorgar 1,5 puntos por cada uno de estos puntos si han sido correctamente explicados o por otros puntos adicionales si son correctos y están bien explicados hasta un máximo de 10.

Ahora ya vemos cómo va la cosa: si te piden una lista o un conjunto de ideas, te van a dar algo de puntuación por cada elemento que pongas, así que una respuesta incompleta aporta más que una no-respuesta.

Vamos a ver otro ejemplo, en el que no sólo cuenta el contenido sino también el continente (versión resumida):

Eres el IT Service Manager de una organización que se está planteando el cambio de mainframe a cliente/servidor. Prepara un informe para el Director de IT analizando los efectos de este cambio en tus áreas de responsabilidad, poniendo un énfasis especial al apartado de costes, beneficios y problemas que puedan generarse por esta migración. (20 puntos)

Ahora también podríamos escribir otro libro, pero veamos en qué se fijan los correctores:

3 puntos por un informe correcto, bien estructurado y bien escrito, con una estructura de Sumario Ejecutivo y contenido principal dividido tanto en

  • Beneficios Genéricos
  • Costes
  • Problemas

o bien en apreciaciones específicas para cada uno de los procesos.

Adicionalmente, se espera que se enfoquen al menos 8 impactos en el área de costes, 7 impactos en el área de problemas y 5 impactos en el área de beneficios, otorgándose un punto por cada uno de ellos no superando los 20 puntos si se han otorgado los 3 por "estilo".

Eso significa que te puedes llevar 1 punto por cada idea que se te ocurra en el momento del examen, y aunque no estén todas, siempre podrás llevarte 3 puntos por el estilo adecuado en el informe.

Algunas preguntas que yo recuerdo del examen mio:

  1. Relación entre 4 subactividades de la Gestión del Cambio y la Gestión de los Proyectos: Esta me dió mucha rabia.. me acordaba perfectamente del dibujo en el libro del Service Support, pero no me lo sabía.
  2. Indicadores en la Gestión del Cambio que sirvan para evaluar a un proveedor externo: fantástica, gracias a mi experiencia profesional... no la encontrarás en los libros.
  3. Escribir un memorando con el rol, cuatro responsabilidades y dos retos para el Gestor de ITSCM: esta es de las difíciles... larga, en formato especial (memorando... es como escribir un mail, pero en papel) y había que saberse los roles bien e inventarse los retos a partir de los problemas que te vas a encontrar en implantación (por ejemplo).

En general, veremos que el examen de Service Support está muy basado en el libro y se te pedirán cosas "de la biblia", pero el examen Service Delivery es más difícil y más abstracto. Recuerdo haber comentado a la salida del segundo examen algo así como

El primer examen fue relativamente simple, muy basado en el libro azul. Mucho de actividades y metricas, un memo y poca cosa sobre el caso de estudio.
El segundo fue mucho más difícil. Casi nada de actividades y preguntas poco concretas (aporte cuatro argumentos para... ). Yo creo que para aprobar el segundo hay que prepararse bien todo lo que son "Beneficios", "Problemas" y "Costes" de cada uno de los procesos.

24 de agosto de 2007

Cómo aprobar el ITIL Service Manager (II)

estudioUna vez finalizados los cursos de Service Manager, te toca estudiar. Tal y decía un anónimo comentarista en el post anterior, Exin aconseja cerca de 320 horas de estudio, contando con las 80 horas de curso presencial, pero ese tiempo es simplemente una estimación que va a variar sensiblemente con tu capacidad de aprendizaje y con la experiencia que tengas previamente.

La etapa de Estudios

Dependiendo de la planificación que haya de cursos y exámenes, tendrás más o menos tiempo para estudiar, pero normalmente debería oscilar entre las 3 y las 6 semanas. Con esto me refiero al tiempo que transcurre desde que terminas el segundo curso y hay una convocatoria a examen. Durante ese tiempo tendrás que estudiar bastante y preparar cada uno de los procesos, a la vez que sigues trabajando y tratando de llevar una vida normal... así que vas a dormir poco, posiblemente.

Los principales consejos que te puedo dar durante este tiempo:

  1. Estás estudiando para el ITIL Service Manager: no lo olvides. El examinador no querrá saber lo bueno que eres en Six Sigma ni CMMI, sino lo bueno que eres en ITIL. Aquí tu experiencia cuenta, pero sólo si sirve para apoyar lo que dicen los libros. Cuando estaba estudiando encontré decenas de cosas que no me gustaban en los libros, que ya están obsoletas, que son mejores en COBIT o cualquier otro estándard... en el momento del estudio y del examen eso no interesa. Lo que dice "la biblia" va a misa (al menos durante las 6 horas de exámenes) así que estudiate la biblia y no te desvies de sus pasos.
  2. Estudia de memoria solo aquello que sea necesario: No te vas a poder aprender de memoria los dos libros de Support y Delivery, así que guarda tu memoria sólo para aquello que realmente sea importante. Sobre todo en el examen de Service Support, te harán preguntas del tipo "Describir las actividades del proceso XXX". Aqui seguramente te darán más puntos por decirlas todas y, si además las dices en orden, un par de puntillos extra.
  3. Mnemotecnia: Yo tengo muy mala memoria, así que tuve que usar trucos de mnemotecnia para recordar esas actividades en orden. La más famosa de todas es la frase que resume las actividades de la Gestión de Configuraciones: "Perhaps, I Can See Vampires" (Plan, Identify, Control, Status accounting, Verification & audit). Pues como esa, hay varias y mejor aún si te las inventas tu, porque seguro que no se te olvidan.
  4. Hacer Esquemas: A mi personalmente me ayuda mucho hacer esquemas y resúmenes. Es decir, escribir lo que quiero aprender. Durante el curso, mucha gente se intercambió esquemas, "fact sheets", "mind maps" y demás documentación bajada de Internet o obtenida en las intranets de sus compañias. Yo me las quedé, por si me hiciera falta consultar algo, pero en realidad lo que hice para estudiar fue hacerme mis propias "fact sheets" cada vez (y me las hice 2 o 3 veces por proceso). El contenido de cada esquema debe ser:
    • Definiciones más importantes del proceso
    • Actividades y SubActividades
    • Entradas y Salidas
    • Indicadores
    • Relaciones con otros procesos
    • Job Descriptions (sobre todo para Delivery y para el Change Manager)
  5. El caso de Estudio: el caso de estudio es un documento que te entregarán al final del segundo curso y que es una descripción de una compañia ficticia sobre la que versará todo el examen. Es decir, muchas de las preguntas del examen serán al respecto de las Gestión de Servicios TIC en la compañía XXX . No es necesario que te lo sepas "de pe a pa" porque te lo darán como parte del enunciado del examen, pero debes haberlo leido y analizado un par de veces para, sobre todo, tener agilidad en las respuestas.
  6. Practica la escritura: No estamos acostumbrados a escribir a boli, así que debes entrenar tus muñecas para resistir 3 horas seguidas escribiendo.
  7. Entiende lo que estudias: llegado el momento del examen, el conocimiento debe fluir solo. No debes "recordar la respuesta" sino que debes "saber la respuesta"... recordar requiere un tiempo para rescatar de la memoria. Saber es inmediato, así que debes saber las cosas y no recordarlas.
  8. Utiliza los exámenes de ejemplo: Exin vende un libreto con dos examenes de ejemplo (creo recordar). Cómpralo (o si estudias en grupo, comprenlo entre todos) y haz los examenes de pruebas, así verás cómo son el tipo de preguntas que te van a hacer.

22 de agosto de 2007

Cómo aprobar el ITIL Service Manager (I)

Cuando estudiaba para pasar el examen del ITIL Service Manager (Managers Certificate in IT Service Management) pensé en escribir uno o varios artículos explicando mis ideas al respecto de cómo se puede obtener esta difícil certificación, pero mi sentido de la prudencia me dictó esperar.. ¿Cómo escribir sobre la técnica para aprobar si aún no había hecho el examen y, sobre todo, si aún no sabía si había aprobado o no?

Ayer me llamaron por teléfono para darme la noticia de que había aprobado los dos exámenes, y hoy me llegó el email en el que me decían la nota: ahora sí que puedo explicar cómo aprobé los dos exámenes de Service Support y Service Delivery a la primera.

itil diamonds

Prerrequisitos:

Los conocimientos requeridos para poder superar los exámenes son:

  1. Estudios de grado medio o superior, o profesionales con una gran experiencia práctica o autodidactas
  2. El certificado de fundamentos de gestión de servicios (basado en ITIL®) (ITIL Foundations)
  3. Buena capacidad de comunicación oral y escrita
  4. Aptitudes para la oratoria, para la elaboración de presentaciones, para la preparación de reuniones y el trabajo en equipo
  5. Al menos dos años de experiencia profesional como gestor o consultor en el campo de la gestión de TI

Oficialmente, los requisitos para poder asistir al examen son los siguientes:

  1. Análisis de los procesos de la gestión de servicios TI dentro de una organización
  2. Diseño de la estructura de organización
  3. Descripción de los procesos de la gestión de servicios TI
  4. Evaluación y auditoria de los procesos de gestión de servicios TI
  5. Implementación de los procesos de cambio
  6. Redacción de reportes e informes
  7. Aptitudes de gestión

Es obligatoria la asistencia al curso de preparación. Este curso son 80 horas de formación en la que se tratarán uno por uno los diferentes procesos del núcleo de ITIL, en Service Support y Service Delivery.

Durante el Curso:

Son 80 horas de formación (intensas, en 2 semanas de trabajo habitualmente) en las que habrá una gran componente práctica y se realizarán muchos ejercicios, tanto en grupo como individuales. Los profesores realizarán una evaluación continua de cada uno de los alumnos donde analizarán aspectos como los puntos 3 y 4 de los conocimientos necesarios y tu capacidad en el punto 7 de los requerimientos (Aptitudes de Gestión).

Personalmente, creo que es en esta parte donde más se aprende en el curso: si traes el Foundations bien aprendido y ese par de años de experiencia que te piden, de los libros Service Support y Service Delivery poca cosa te van a enseñar, pero... siempre se puede aprender algo de técnicas de reuniones, gestión de proyectos, presentaciones en publico, desarrollo oral y escrito, etc.

Si, además, tienes la suerte de que el curso sea multi-empresa, tendrás la oportunidad de trabajar en equipo con personas de otras organizaciones y aprenderás mucho de su estilo, técnicas, maneras de hacer, etc.

Los consejos a seguir en esta etapa:

  1. Aprovecha el tiempo: Tienes 80 horas para pensar únicamente en ITIL, no las desperdicies.
  2. Sácale el jugo a tus compañeros: Es una ocasión única para compartir e intercambiar experiencias, sensaciones, opiniones, tarjetas de visita,etc.
  3. Aprende a escribir: Cada examen dura 3 horas. En esas 3 horas tienes que desarrollar muchas ideas, así que debes acostumbrarte a sintetizar, no soltar unos rollos impresionantes, acotar las ideas y expresar lo más importante. Utiliza las prácticas del curso para aprender a hacer esto.
  4. Estudia todo el tiempo que puedas: Durante esas semanas de curso  estarás inmerso en un ambiente en el que sólo se hablará de ITIL... pero tu debes aprovechar todo el tiempo posible para estudiar: 10 días de curso, 10 procesos: eso hace que te puedas preparar cada día el proceso que te van a explicar al día siguiente. ¿Puedes ir al centro de estudios en transporte público? Pues esa media horita en metro, tren o guagua son esenciales para preparar el tema del día siguiente.
  5. ¿Tienes Pareja? ¡Avísale de dónde te metes! Las dos semanas de curso son intensas, como te he dicho antes: no sólo tendrás 80 horas de clases, sino que además te tienes que preparar la clase del día siguiente y hacer ejercicios puntuables que te pondrán los profesores "como deberes", así que en casa te van a ver poco el pelo durante este tiempo... avisales y pideles que te ayuden a concentrarte.

Bueno, hasta aquí esta primera parte. Seguiremos más adelante con consejos sobre los momentos de estudio posteriores al curso y sobre las técnicas a utilizar durante el examen.

16 de agosto de 2007

El IT Skeptic se deja ver

Hacía más de un año que intercambiaba algún que otro mail con un compañero de penurias de casi justo mis antípodas, y resulta que hoy ha desvelado un secreto que realmente me había costado mantener: la verdadera identidad de Mr. IT Skeptic.

Para los que no lo conozcan (lo dudo, a estas alturas) dire que es un escritor que se ha dedicado a poner antre las cuerdas a ITIL, el itSMF y otros cuerpos de conocimiento relacionados con la Gestión de Servicios IT, añadiendo grandes dosis de sentido comun a sus artículos y diciendo lo que nadie se ha atrevido a decir.

Ha provocado grandes discusiones y ha logrado atraer la atención de "los grandes" en este mundillo, pero siempre desde el anonimato. Hasta ahora, en que ha "salido del armario" y se ha dejado ver.

Bienvenido, Mr. Rob England!

Ahora nunca más podré decirles a mis amigos con cara enigmática "Yo se quién es el IT Skeptic, pero no te lo puedo decir"... ¡Lástima!

8 de agosto de 2007

La métrica como un medio y no como un fin

calibreVoy avanzando en la lectura concienzuda del libro Continual Service Improvement, de la V3. Hay cosas que me gustan y cosas que no me gustan y en general la sensación no es del todo buena (quiero esperar a haber leido al menos dos libros más antes de haberme formado una opinion completa, pero por ahora la sensación es más de estar leyendo whitepapers que una Best Practice)

Pero he leido una frase, pequeñita y escondida, que contiene algo muy importante:

However, it must be remembered that although the measurement of progress is vital, it is not the end product; rather, it is a means to an end. [...]

Aún así, debemos recordar que, a pesar de que la medición del progreso es vital, ésta no es el producto final: más bien es un medio para conseguir un fin. [...]

Es decir, como decía en el artículo sobre las claves para el éxito de un cuadro de mando en ITSM  en la clave #8, medir y reportar los resultados no es un fin en sí mismo, sino un medio, un instrumento que se debe utilizar para la toma de decisiones, para la alineación y para el Gobierno de las TIC.

Vayamonos acostumbrando a detalles como este, porque ITIL V3 quiere abarcar mucho conocimiento en poco espacio de libros, así que hay que leer entre líneas y "expandir" cada uno de los conceptos introducidos con nuestra propia experiencia y conocimientos.

3 de agosto de 2007

¡Arde Canarias!

Quería haber escrito un post de esos "off-topic" al respecto, pero todo lo que me salía era rabia, odio y malas vibraciones.

Mi madre, que es mucho más emotiva, sensible y positiva que yo, ha dicho todo lo que a mi me hubiera gustado decir, así que sólo queda pedir que los autore de este y de todos los demás incendios forestales se pasen el resto de su vida reforestando cada metro cuadrado de bosque quemado.

Arde Canarias, y con ellas mi alma.

 

La magnitud de la tragedia:

Sin título-5.eps

1 de agosto de 2007

Un vaso de agua (al enemigo)

agua Tenía ganas de usar este título en homenaje a Radio Futura, y hoy mientras iba pensando sobre cuáles son esos acercamientos al "enemigo" que tienen que hacer los departamentos IT se me fue moldeando este artículo (con su título y todo).

Las áreas IT tiene toda una serie de grandes retos que superar, como todos en esta vida, pero hay un par de ellos que son los grandes clásicos: desde el punto de vista externo, están conseguir la alineación con los clientes y garantizar la satisfacción de los usuarios.

Desde el punto de vista interno la cosa se complica, pero yo creo (en este momento de mi vida) que hay tres grandes retos organizativos: conseguir cerrar la brecha entre operación y desarrollo, conseguir cerrar la brecha entre "ventas" (relación con el cliente) y "producción" y conseguir cerrar la brecha entre soporte y el resto del mundo.

Como podemos ver claramente, estos tres retos se pueden resumir simplemente en "conseguir que trabajemos como un equipo", pero en las grandes organizaciones la vision de equipo es dificil de mantener. Y aquí es donde el mundo del ITSM puede ayudar: si nos fijamos bien, en este mundillo todo gira alrededor del servicio. Con todo girando alrededor del servicio podríamos pensar que se reduce la posibilidad de esta "brecha" entre unidades organizativas, ya que ahora lo que prima es el servicio y no el departamento.

Así, la brecha entre operación y desarrollo se cierra cuando gracias a la definición del servicio dentro del catálogo, los chicos de desarrollo entregan a operación algo que realmente es operable y desaparece la frase mítica: "Unos pasan a producción y otros se comen el marrón".

Por otro lado, la brecha entre "ventas" y "producción" se reduce gracias a que el proceso SLM se encarga precisamente de acercar estos dos mundos: lo que se vende se debe poder producir y se va a producir lo que se ha vendido.

Finalmente, cerrar la brecha entre soporte y el resto del mundo va a ser más dificil. Yo veo especialmente importante esta separación cuando, por ejemplo, las incidencias deben ser escaladas a otros grupos organizativos cuyo foco principal no es la resolución de incidencias. Así, una incidencia compleja escalada a un grupo de administración de bases de datos puede quedar en el olvido si este grupo tiene otras prioridades (como finalizar el proyecto en el que están inmersos).

¿Quién debe priorizar, en este caso? Esta es una pregunta más difícil de responder y que posiblemente se merece un post completo, pero a priori está claro que aquello de "la esponsorización de la dirección" es elemento clave para esta pregunta, así como un correcto análisis del impacto.

Personalmente, creo que en condiciones de igualdad, debe tener prioridad una incidencia sobre un nuevo proyecto ya que la incidencia afecta a algo que está en producción.

¿Qué opinas tú? ¿A quién le das el vaso de agua?

 

 

30 de julio de 2007

TOGAF y el Catálogo de Servicios

Togaf Cuando se inicia un proyecto de definición de un Catálogo de Servicios, uno de los primeros pasos es obtener la lista de los servicios que se van a tratar y a documentar. Está claro que para la organización TI es necesario llegar a documentar todos los servicios en su catálogo, pero para seguir  un métido de aproximaciones sucesivas y poder obtener entregables a corto plazo, la idea es obtener primero la lista de los servicios y abordar su documentación detallada por "tacadas" de mayor a menor importancia para el resto de la organización (a.k.a "el negocio").

Llegados al punto en que hay que comenzar a obtener la lista, podemos comenzar desde cero o aprovechar algo de información sobre "los servicios más comunes que tienen todas las organizaciones", y es aquí donde puede servir de gran ayuda un apartado especial de TOGAF llamado Taxonomía de Aplicaciones.

No es aplicable al 100%, pero puede servir como base para desarrollar esta lista.

¡Buena Caza!

27 de julio de 2007

Mejora Continua

Todo pasa y todo queda,
pero lo nuestro es pasar,
pasar haciendo caminos,
caminos sobre el mar.

Ante la entrada de ITIL V3, se abrió en el seno del itSMF España un antiguo debate (ver aquí o aquí ) sobre la terminología a utilizar de forma oficial y unificada, tanto en los libros oficiales de ITIL como en los exámenes oficiales (de EXIN) y en la norma española UNE-ISO/IEC 20000.faro

Después de mucho diálogo y arduas discusiones, después de evaluar los pros y los contras, después de evaluar el impacto en el sector, en el mercado, en los estándares, en las personas... después de un ceñudo, largo y dificil debate, la Junta de Gobierno del itSMF España ha decidido por votación y con la participación de todos sus comités que se realizarán cambios en el diccionario oficial para ajustarlo a la realidad social que todos vivimos en el día a día.

Así, la Junta de Gobierno ha decidido

1. Respetar el nombre de los procesos de V2 que coinciden con la V3, y
cambiar sólo tres de ellos debido a que el uso habitual en las empresas no
coincidía con el término estandarizado.

Los términos de V2 que se CAMBIAN son:
Gestión del Incidente se cambia por “Gestión de Incidencias”
Gestión del Problema se cambia por “Gestión de Problemas”
Gestión del Cambio se cambia por “Gestión de Cambios”

Los términos de V2 que se MANTIENEN son:
Centro de Servicio al Usuario (SD)
Gestión de la Comfiguración
Gestión de la Entrega (V2)
(como en V3 cambia el nombre es "Release and Deployment Management" y el
alcance de release es otro distinto, se acuerda el nombre del porceso a “
Gestión de la Versión y del Despliegue”
Gestión del Nivel de Servicio
Gestión de la Capacidad
Gestión de la Disponibilidad
Gestion de la Continuidad del Servicio de TI
Gestión Financiera (v2) en V3 deja de ser proceso como tal, pero existe el
término
Gestión de la Seguridad de la Información
Gestión de Suministradores
Gestión de la Aplicación (actividad)
Gestión de Aplicaciones (función)
Gestión de Redes
Gestión Técnica
Operación de TI
Informes del Servicio

Además para el resto de la terminología se va a abrir al público un periodo
de sugerencias y debate en la web de itSMF.es  sobre el excel realizado por
el GT de Terminología.

Y por lo tanto se abre también un debate para la discusión y posterior aprobación del diccionario de términos ligados a ITIL V3. Este debate se realizará a través del foro del itSMF España y se puede consultar aquí.

Caminante, son tus huellas
el camino y nada más;
caminante, no hay camino,
se hace camino al andar.

25 de julio de 2007

La clave de la alineación

En estas últimas semanas me ha tocado hablar con varios clientes/compañeros sobre el asunto de la tan famosa y deseada alineación de las TIC y el Negocio. A pesar de que ahora la moda es decir que "no hay que alinearse, sino que hay que integrarse; que el 'negocio' somos todos", es cierto que alinear los objetivos de cada uno de los departamentos de una organización con los objetivos globales que se persiguen como organización es algo realmente necesario.

COBIT, como marco de trabajo orientado especialmente al gobierno de las TIC, nos ofrece un modelo especialmente interesante para lograr esta alineación. El mecanismo es bonito en su simplicidad:

1.-Objetivos de Negocio

Para comenzar, se obtiene una lista de los objetivos de negocio, extraidos probablemente de su Plan Estratégico (ver entrada La Madurez como prerrequisito para IT Governance ). El modelo que plantea COBIT clasifica, además, esta información según los cuadrantes establecidos para un Balanced ScoreCard ( Kaplan y Norton ).

2.- Objetivos de IT

A continuación, se definen los objetivos de IT y se relacionan con cada uno de los objetivos de negocio. Aquí estamos viendo claramente cómo contribuiremos desde IT a cumplir los objetivos de Negocio y podemos cuestionarnos claramete cualquier objetivo IT que no esté relacionado con un objetivo de negocio: si no aporta al cumplimiento del objetivo global y común, ¿para qué está?

3.- Procesos de IT

El siguiente nivel es saber qué procesos IT deben intervenir en la consecución de estos objetivos departamentales. Así podremos obtener un mapa que refleje cuáles son los principales procesos que contribuyen a cada uno de los objetivos de IT (y por consiguiente a los objetivos de Negocio).

4.- Métricas

Por último, el modelo de métricas de CobiT está pensado para definir un conjunto de indicadores que nos permitan saber cómo de bien se están cumpliendo los objetivos de las actividades que hay dentro de los procesos, cómo están contribuyendo estas actividades al cumplimiento de los objetivos del proceso y cómo están contribuyendo los procesos al cumplimiento de los objetivos de IT.

Lo que siempre me ha llamado la atención de este modelo es que, siendo la gran clave de la alineación planteada por COBIT, todo esto está "escondido" en los anexos del manual del framework, así que escapa habitualmente de la lectura diagonal que gran cantidad de usuarios de COBIT realiza.

Por último, recordar que COBIT es un framework, un marco de trabajo, algo que es una simple guía que debe ser adaptada a las necesidades concretas de cada organización. Es decir, en la lista de objetivos de negocio que se propone no están los objetivos de negocio de tu compañía, sino los que se inventó un estudioso señor de Gartner que vive al otro lado del Atlántico, en la lista de objetivos de IT no están tus objetivos de IT y en la lista de métricas no están todas las métricas que puedas necesitar.

BIBLIOGRAFIA:

CONTROL Journal (I)

CONTROL Journal (II)

24 de julio de 2007

Un whitepaper interesante

He encontrado un whitepaper interesante titulado Defining, Modeling & Costing IT Services publicado por los chicos de Pink Elephant en el que se habla de un par de asuntos de gran importancia:

  1. Una definición (más) del concepto Servicio
  2. Los 4 pasos necesarios para obtener la lista de servicios
  3. La separación entre servicios profesionales y servicios IT que tanto he remarcado en mis anteriores artículos sobre Catálogo de Servicios
  4. La necesidad de un modelo de costes basado en servicios
  5. La necesidad de que este modelo de costes tenga en cuenta aquellos servicios profesionales que no son directamente relacionables con los servicios IT ya existentes.

El paper está escrito por Troy DuMoulin (no lo dice explicitamente, pero he encontrado una versión anterior en la que sí que lo decía claramente), co-autor del libro Defining IT Success Through the Service Catalog junto con Rodrigo Flores y Bill Fine, de NewScale.

HP y la CMDB Federada

Recuerdo que hace poco más de un año comencé este blog hablando de lo dificil que iba a ser ver implementado de una forma real y efectiva el concepto de FCMDB . Poco más tarde, escribía otro artículo buscando la base de estandarización que haría falta, y mencionaba como estandard emergente e interesante el DCML y me llamaba la atención que HP no estuviese en la lista de participantes del consorcio que estaba desarrollando este estándard.

Pasó un tiempo y HP compró Peregrine y entonces todos los rumores apuntaban a que la CMDB de HP sería la de Peregrine, porque el AssetCenter parecía ser "el producto estrella", pero entonces HP compró Mercury y los planes cambiaron: en el último HP Technology Briefing al que pude asistir, hace apenas un mes, se hicieron unas cuantas presentaciones muy interesantes sobre la uCMDB (Universal CMDB), producto que HP coloca en el centro de su estrategia de integración entre los diferentes "centers" y que implementa realmente el concepto de CMDB Federada (confieso que fui muy escéptico ante todo aquel que desde HP me hablaba de federación hasta que fui a Berlin y lo vi).

Pero en esas presentaciones pregunté por los estándares utilizados para modelar la CMDB y la respuesta fueron algunas siglas propietarias, el presentador no conocía ni de la existencia del DCML ni (¡sorprendentemente!) de la iniciativa conjunta entre los grandes fabricantes que se inició el año pasado (ver este post y relacionados).

Pero en realidad todo se estaba cocinando... salía aroma a FCMDB de la cocina de HP, pero los pinches no sabían qué estaba preparando el chef.

Hoy se ha dado la noticia y es fresquita: HP ha comprado OpsWare, uno de los esponsores de DCML, fabricantes de un producto llamado OpsWare OMDB (Operational Management Database) y líderes indiscutibles (junto a nLayers) en la automatización/descubrimiento de CPDs y BackEnd

Billboard-HP

Vamos, que HP está decidida a posicionarse en el mundo del descubrimiento (tienen ya 3 o 4 productos), de la automatización del cambio (perdón! de los cambios ;-) (para esto tienen tambien al menos 2 o 3) y de la CMDB (otros 3 o 4 productos en el portfolio).

De todas formas, siempre hay que escuchar todas las versiones de la historia, y aqui queda un enlace al artículo "HP buys my company Opsware for more than $1.6 billion in cash" en el blog de Marc Andreesen, uno de los fundadores de OpsWare y poseedor de un más que interesante curriculum.

Como yo decía, hace 1 año faltaban 4 ó 5 para ver una FCMDB en marcha y madura... ahora sólo faltan 3 ó 4.

20 de julio de 2007

TOGAF 8.1 y COBIT

He leído en el blog de Serge Thorn que en un trabajo conjunto entre ISACA y The Open Group se ha desarrollado la guía de mapeo entre estos dos estándares (siguiendo la trayectoria de publicaciones de mapeo entre estándares que ha seguido ISACA desde el nacimiento de COBIT 4.0).

Tal y como dice Serge, el documento está disponible para usuario de The Open Grup en las direcciones

http://www.opengroup.org/bookstore/catalog/w072.htm

http://www.opengroup.org/bookstore/catalog/w072a.htm

y https://www.opengroup.org/architecture/wp/

y adicionalmente lo podremos encontrar para usuarios de ISACA en

http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/ContentManagement/ContentDisplay.cfm&ContentID=33100

TOGAF es un estándard nacido en 1995, también patrocinado por el Departamento de Defensa estadounidense (al igual que CMMI, por ejemplo) enfocado hacia la definición, implantación y mantenimiento de Arquitectura Empresarial (enterprise architecture) y que tiene como punto principal la gestión de requerimientos.