Búsqueda


28 de abril de 2006

¿La magia recorre tu cuerpo?

En mis primeros cursos de ITIL recuerdo que siempre había un momento en el que notaba que a los alumnos les empezaban a encajar las cosas en su mente, comenzaban a ver la foto completa y en ese momento explicaba que cuando eso te pasa, sientes “la magia recorrer tu cuerpo”. Esto es una referencia a las Crónicas de la DragonLance en las que el mago Raistlin tenía más habilidades para ejercer la magia que la gran mayoría de los demás magos a pesar de su juventud.

En los momentos en que Raistlin tenía que utilizar la magia, cada hechizo le consumía las fuerzas de forma que a pesar de sus extraordinarias habilidades no podía realizar mucho más de dos conjuros seguidos. En una situación muy crítica, el mago tuvo que gastar todas sus energías para realizar un conjuro especialmente complicado, y las autoras describían el momento contando que “a pesar de lamentable estado, Raistlin sintió la magia recorrer su cuerpo subiendo desde los pies hasta llegar a concentrar las pocas fuerzas que le quedaban para susurrar las cuatro palabras que componían el conjuro”.

Esa es la sensación que me recorre cuando siento que mis alumnos comienzan a entender cómo los conceptos de la Gestión de Servicios son la agrupación total de los conocimientos que uno ha estado amasando durante años hasta ver que se fusionan todos en uno y surge la magia de ITIL. Han pasado años, al menos seis desde aquellos primeros seminarios y ahora la sensación ya no es tan intensa cuando los alumnos comienzan a ver la luz. Supongo que principalmente porque ahora los alumnos vienen mucho más preparados, y por lo tanto no les estás iluminando con tantísima intensidad como hace seis años (conceptos como Servicio, Proceso y Gestión ya han sido asimilados completamente por el mercado), pero también hay otro factor importante: yo se ahora más que hace seis años. Y ya no es ITIL “la punta de la pirámide”, sino que es “la punta del iceberg”: hay mucho más que hacer y veo claramente que ITIL se queda corto en muchísimos aspectos, por lo que es necesario complementar ese conjunto de buenas prácticas con otros estándares, marcos de trabajo o recomendaciones. Al fin y al cabo, ¿dónde dice en ITIL que es bueno disponer de un plan estratégico para la compañía o para el Departamento de TI? o bien, ¿cuáles son los pasos que se deben dar para exigir la devolución de un servicio a un proveedor de externalización?

Hay toda una serie de procesos que no están descritos en ITIL y que son profundamente necesarios para el buen gobierno de las TIC en una compañía, y es por eso por lo que más allá de las Best-Practices tenemos la necesidad (cada vez más imperiosa) de acudir a otras fuentes:

COBIT en sus Objetivos de Control de Alto Nivel, establece un conjunto de procesos mucho más amplio que los que establece ITIL “troceados” en cuatro dominios. La lástima de COBIT es que dice claramente el qué, pero no dice el cómo. Es decir, tenemos una buena guía de los procesos, actividades y controles que se deben establecer, pero no tenemos (a diferencia de ITIL) una guía de buenas prácticas a la hora de implementar y ejecutar los procesos.

Con la entrada en escena de COBIT 4, se ha dado un importantísimo paso adelante, ya que la nueva versión está mucho mejor estructurada y es mucho más clara que la anterior. Adicionalmente y previo a la publicación de COBIT 4 se realizó un trabajo conjunto entre ISACA , ITGI y la OGC para redactar una valiosa guía de referencia cruzada que plantea la combinación de ITIL, COBIT e ISO 17799.

Por otra parte, no tan conocido como el mundo COBIT, pero especialmente orientado a empresas proveedoras de servicios, podemos acudir a los modelos de la Carnegie Mellon: eSourcing Capability Model for Service Providers (eSCM-SP) o bien el eSourcing Capability Model for Clients (aún en desarrollo).

Escm

¿Qué aporta este modelo adicionalmente a los modelos que podemos encontrar en ITIL, CMM o COBIT?

Podemos encontrar toda una serie de comparativas entre los diferentes modelos aquí, hay que seguir leyendo (¡y mucho, que el eSCP es grande!) porque en realidad hace muy poco que lo conozco y tengo que estudiar mucho, pero una primera aproximación más visual que el “tocho” de libro la puedes encontrar aquí.

24 de abril de 2006

METRICS for IT Service Management

La semana pasada me llegó mi copia del libro Metrics for IT Service Management y he dedicado unas horas a repasar el trabajo realizado. Tengo que decir que estoy especialmente orgulloso de que mi nombre aparezca en la reseña de este libro, porque estoy seguro de que se convertirá en un Best-Seller del mundo de la gestión de servicios TIC.
La primera parte del libro incluye todo un fondo teórico al respecto de cómo construir las métricas adecuadas para la correcta gestión de los servicios TIC y qué características debe tener una buena métrica. No olvida todo el apartado de consideraciones al respecto de mecanismos de recolección, tiempos, amplitud de muestras, etc. y establece el concepto de "Catálogo de Métricas", es decir el conjunto de atributos que debemos definir para establecer una métrica como parte de nuestro sistema de gestión de servicios TIC. Aquí hay un apartado que me ha gustado especialmente y que está dedicado a explicar cómo una métrica impuesta puede condicionar el comportamiento de la organización medida y por qué hay que tener un especial cuidado con la definición de estas mediciones: si marcamos un objetivo a cumplir con respecto, por ejemplo, al tiempo que las llamadas de servicio permanecen abiertas en el ServiceDesk (ServiceCall Duration), corremos el riesgo de que los técnicos del Service Desk cuando ven que una llamada lleva demasiado tiempo abierta nos pidan que cerremos esa llamada y abramos otra (¿Cuántas veces no nos ha pasado algo así?). Este tipo de efecto colateral no mejora la calidad de servicio sino que lo empeora… aquí tenemos un refran para eso (que me imagino que no debe existir en el mundo anglosajón, porque si existiera formaría parte de las Best-Practices): Hecha la Ley, Hecha la Trampa
La segunda parte es definitiva, ya que responde al espíritu inicial del libro de convertirse en una fuente importante para el benchmarking: proporciona un amplio conjunto de métricas para los diferentes procesos de gestión. Este es un trabajo que era necesario realizar, ya que cada organización establece sus propias métricas y la pregunta más frecuente es "¿Cómo lo miden en otros sitios?"
Hay dos puntos importantes a destacar al respecto de esta recopilación de métricas:
  • Por una parte, no se describen métricas para medir el servicio en sí, sino para medir o caracterizar los diferebtes procesos de gestión del servicio TIC. Es decir, no encontraremos las métricas más habituales para hacer el seguimiento del servicio Hosting de Aplicaciones pero sí que encontraremos las recomendaciones al respecto de métricas necesarias para realizar el control del proceso de Gestión de Versiones.
  • Por la otra, aparecen valores orientativos que no se deben seguir al pie de la letra, sino servir de guía para establecer en cada organización los valores apropiados (de hecho, en el texto se describen estos valores como necesarios para dar consistencia a los ejemplos de cálculo y agregación de métricas en indicadores).
¡Muy recomendable!

19 de abril de 2006

Desenfocado

Así es como veo el asunto ahora: desenfocado. No ha pasado un mes desde que comenzara este blog con un artículo sobre las CMDB federadas y me encuentro en mi cuenta de bloglines este artículo: BMC, Fujitsu, IBM, HP launch CMDB initiative.

No deja de ser curioso que el artículo pone en boca de Tom Bishop el interés de crear un estándard para el intercambio de metadatos relativos a la CMDB, aquello que en el segundo artículo sobre las CMDB federadas explicábamos como algo imprescindible para la propia existencia de este concepto.

Lo que me ha dejado confuso y desenfocado ha sido la frase entrecomillada, o sea: literal, que ha dicho este señor ( y la pongo aqui transcrita directamente del artículo mencionado): "We intentionally decided not to pursue this within a standards group first because we wanted to make some quick progress,"

¿Qué quiere decir exactamente con que quieren hacer progresos de una forma rápida?
¿Acaso no es progresar de una forma rápida el adoptar y utilizar los trabajos ya hechos por una entidad como OASIS que además cuenta entre sus esponsors a la propia BMC?

O quizás estoy totalmente equivocado y el DCML no sirve para federar CMDBs, pero no es lo que deduzco de leer (de nuevo) el whitepaper Demystifying the CMDB, los Casos de Uso de DCML, y una novedad (para mi): las especificaciones del metamodelo de Microsoft.

No se, no lo entiendo. Por favor, si alguien puede añadir un poco más de luz en este asunto, que lo haga y quedare profundamente agradecido.

Mientras tanto, les recomiendo este whitepaper sobre DCML e ITIL.


13 de abril de 2006

El virus manual que infecta los blogs

Hoy he visto un blog infectado por el virus manual.

Me ha llamado la atención, porque al fin y al cabo no deja de ser una ridiculización de uno de los factores de contagio de virus más importantes que hay: la ingeniería social. ¿Se acuerdan de aquel primer virus que salió al mundo DOS? Debía correr el año 86, más o menos, y de repente en los PC's de todo el mundo apareció una pelotita que botaba por la pantalla. Sin darte cuenta te contagiabas y no sabías cómo y no había forma de eliminarlo, porque no existian ni McAfee, ni Norton Antivirus y mucho menos Panda ni TrendMicro. Lo único que había en aquella época eran las Norton Utilities y las PC-Tools (qué maravilla de programas!).

Bueno, aquellos virus se contagiaban infectando el sector de arranque de los diskettes, quedaban residentes en memoria (oh! los principios del multitasking en los PCs) y contaminaban cualquier diskette que metieras en tu fantástica lectora de floppies de 5"1/4. Ahora las cosas son diferentes: siguen existiendo los virus que se contagian por contaminar el MBR y los hay que modifican las cabeceras de los ejecutables y hacen cosas terribles, pero los que más rápido se propagan son esos que te llegan por mail en plan "Mira que foto de qué peaso tía" o "Mira que presentación más divertida"... tu los abres sin ni fijarte quién te los ha mandado (incluso da igual: te los ha mandado alguien conocido y todo) y ¡¡plaf!! ¡Contaminado!.

Encima va y envia un mail a todos tus contactos con el mismo ficherito y de paso les da toda la lista de direcciones a un grupo de Spammers que a partir de hoy te freirá el buzon de entrada con ofertas de productos inimaginables.

¿¿Y cómo ha conseguido entrar y propagarse ?? Pues muy simple: porque un usuario le ha dado doble click al anexo que venía en el mail. A eso se le llama ingeniería social: gran parte des esfuerzo del desarrollo del virus se centra en conseguir hacer algo lo suficientemente atractivo como para que la gente pique el anzuelo. Recuerdo que cuando instalamos el Lotus Notes por primera vez en mi empresa y descubrimos el uso de formularios, texto rico, botones y cosas parecidas, el primer uso que hice de semejantes conocimientos fue mandarle un mail al compañero A diciendo "pica este botón y veras qué foto de tía que sale". El botón efectivamente presentaba una imagen que se llamaba "OpenWide.gif" y le mandaba un mail al compañero B poniendolo verde. Solo habia que sentarse, esperar a ver la bronca que se montaba entre A y B y hartarse a reir... qué rapidos que somos para usar los conocimientos para el cachondeo, eh?

Pues aqui está el virus manual... el colmo de los colmos: no hace falta ponerle logica de propagación, ya lo propagamos nosotros mismos. Pasará todos los filtros de los antivirus, y si miramos en el Google, ya hay más de 100.000 entradas y en All the Web vemos más de 1500. SIn embargo, a pesar de que este es un virus manual simpático y que no hace nada, los Argentinos han sido contagiados por el virus Gallego que si que es dañino.

Total, que me he dejado contagiar... aqui está:

Les presento al Blog.Worm

Blog.Worm

10 de abril de 2006

ITIL y la escasez de médicos

El otro día iba en el coche hacia el trabajo por la mañana escuchando la radio, y dieron una noticia que me llamó la atención: el Ministerio de Sanidad daba la alerta de la escasez de médicos que hay. Resulta que hay pocos estudiantes inscritos en las universidades y los médicos que hay en el país emigran a otros paises de la Union Europea donde consiguen salarios más elevados o mejores condiciones laborales de las que pueden encontrar aquí.

Es interesante ver como las necesidades de profesionales en un pais se deben planificar con años de antelación, ya que desde que se comienza a madurar la necesidad hasta que el personal formado está "en la calle" pasan años; y eso es precisamente lo que comentaba hace unos meses con un compañero de trabajo: el boom que se está viviendo en estos ultimos diez o doce meses en el sector del Gobierno de las TIC y de la implantación de procesos ITIL está poniendo en un grave apuro a todas las compañias que se/nos dedicamos a este tipo de actividades; el mercado está "candente" y es difícil contratar a personal cualificado.

En JobStats podemos ver lo que está ocurriendo en un mercado ya maduro como es el británico en lo que respecta a ofertas de trabajo relacionadas con ITIL: un crecimiento exponencial en los últimos 3 años con sus altibajos estacionales. ¿Qué ocurrirá aqui cuando termine de consolidarse la demanda de profesionales?



Hablando con un cliente hace poco, éste me comentaba que "al fin y al cabo, las empresas estan formando y poniendo en circulacion un itilero en unos 3 meses", cosa que me puso los pelos de punta. Un itilero no se hace en 3 meses, esto (al menos para mi) necesita un buen tiempo de sedimentacion y de comprensión, además de horas de vuelo para hacer las cosas medianamente bien. Y de este pensamiento pasé al siguiente... en un artículo anterior salió un comentario sobre la programación orientada a objetos. ¿Cuándo se creó este concepto? Según la wikipedia, sobre el año 67, pero hasta mediados de los 80 no empezó a dar fuerte en los grupos de trabajo dedicados a la programación empresarial, y en aquellos días pocos eran los programadores que entendieran y supieran de qué iba esto de los objetos, las clases, la herencia y todas esas cosas.

Poco a poco fue calando y a medida que las empresas iban solicitando gente con conocimientos de OOP (cambió no sólo la forma de programar, sino la forma de analizar y diseñar las aplicaciones y eso hizo que muchos tuvieran que reinventarse laboralmente) los planes de estudio de academias, institutos de FP y universidades iban añadiendo temario relacionado con las OOP y los fabricantes de herramientas de programación hacían grandes campañas casi que regalando las licencias de sus productos a los centros de educación.

El resultado ha sido claro: lo que antes era "una cosa rara", ahora es natural y los chicos que terminan sus estudios entienden la orientacion a objetos y saben usarla, de forma que las empresas no necesitan re-formar o fabricar programadores para este tipo de lenguajes.

Pues exactamente lo mismo es lo que va a necesitar el mercado del diseño, análisis, implantación y seguimiento de los procesos que soportan la provisión de servicios TIC: necesitamos que no sea algo que haya que enseñar, sino algo tan natural como los eventos, las ventanas o la existencia de un centro de atención a usuarios.

5 de abril de 2006

La Resistencia al Cambio

Leo en noticias.com un artículo que habla sobre la resistencia al cambio que se produce en los usuarios cuando se trata de poner en marcha nuevas herramientas, resistencia al cambio en la forma de trabajar, al cambio en los procedimientos o incluso miedo a la eliminación de determinadas tareas que ahora pasan a ser realizadas por el nuevo sistema que se está implantando.

Hoy me ha dado el punto de comenzar este artículo de una forma que se ha convertido en estándar para iniciar un artículo en un blog: “leo en nosedonde algo que me hace pensar y como me hace pensar, me apetece escribir sobre ello y aquí está el resultado”. Y así es: me da que pensar y aquí esta el resultado:


El año pasado cumplí 20 años de trabajos en el sector, y durante todos estos años he tenido que lidiar cambios de todo tipo. Mientras hacía la cola del control de seguridad en el aeropuerto (¡tantos viajes, tantos aviones, tantos aeropuertos!) pensaba en cuáles han sido los cambios más traumáticos que me ha tocado vivir a nivel profesional ,y la conclusión ha sido que los dos cambios más importantes han sido la entrada en mi vida de las ventanas (“y para qué quiero yo que un ordenador haga más de una cosa a la vez” pensaba cuando vi por primera vez un Windows 3.0 ), la programación orientada a objetos (que vino casi simultáneamente con la entrada en nuestra vida de las ventanitas) y los primeros contactos con el mundo ITIL.

Años de trabajo frente al cliente y al usuario final me han ido haciendo ver que la correcta gestión del cambio es de vital importancia si queremos que un proyecto de implantación de procesos llegue a buen puerto. Ojo, que he dicho “gestión del cambio” y no “gestión de los cambios” ni “cambios en la gestión” ni nada parecido: me refiero concretamente a la buena gestión de El Cambio cultural, organizativo y de forma de trabajar que se produce en la organización TIC cuando se realiza una ingeniería de procesos y su implantación.

Muchas veces ocurre que la organización no se plantea el entrar “a fondo” en ITIL, sino que empiezan simplemente comprando e implantando una herramienta que les permita mejorar el HelpDesk , automatizar ciertas tareas y generar algunos informes. Pero aún así y como en la publicidad de SEAT, “ya estás perdido”. Sin planteárselo, se han metido en una implantación en la que (y esto ocurre pocas veces en las Pyme y en las empresas que están empezando su camino en el modelo de madurez) el usuario es el propio personal del Departamento de IT. Y como pasa con los fumadores, que no hay peor enemigo del tabaco que un exfumador, no hay peor usuario que un informático: instantáneamente se convierte en el peor juez de aquello que se está montando e instintivamente ataca a la fuente de la incomodidad: el cambio.

Por estas razones, siempre que comienzo un proyecto en el que haya ingeniería de procesos o implantación de herramientas de gestión para el Departamento de TI, trato de seguir estas 5 reglas de oro:
  1. Escuchar mucho, no sólo a aquellos que te han puesto como interlocutores, sino al usuario.
  2. Tratar de involucrar a los equipos que utilizarán la herramienta o el proceso en su diseño.
  3. Tratar de que no parezca que el trabajo lo estamos haciendo mi equipo y yo: lo están haciendo ellos y se deben sentir orgullosos de lo que se está haciendo porque lo ven como algo propio.
  4. Detectar los quickwins y aplicarlos cuanto antes
  5. Permanecer un tiempo después de la puesta en marcha.

Siguiendo estos 5 pasos conseguiremos que la aceptación del cambio por parte de los usuarios sea un hecho y que la transición hacia las nuevas herramientas/procesos/métodos sea suave y, en la medida de lo posible, agradable.

De todas formas, hay dos cosas más que recordar siempre: la primera es que en todas las organizaciones encontraremos al menos un “follonero” que encontrará todas las pegas y todos los problemas habidos y por haber. CUIDADO CON ESTE! Normalmente lo mejor será no enfrentarse, sino convencerlo o bien contar con el apoyo de los responsables para encauzar toda esa energía hacia algo más positivo.

La segunda es un proverbio chino: “Es fácil cambiar el curso de los ríos y las montañas, pero difícil es cambiar la naturaleza de un hombre.” Cuando implantamos herramientas y procesos estamos cambiando la forma de trabajar de las personas y éstas tienen una inercia impresionante.