Curso ITIL v3 online gratuito

El curso Fundamentos de ITIL ® v3 proporciona una sólida base para entender los conceptos fundamentales de ITIL v3 y para aprender cómo puede aplicarse en una organización real. Analizando los cinco libros básicos de ITIL, podrás repasar los procesos y funciones fundamentales, entenderás el papel que juega la mejora continua a la hora de optimizar el departamento IT, y se sentarán las bases para una relación fructífera entre IT y las áreas de negocio. Conocerás los procesos ITIL esenciales para dar soporte y prestar servicios IT de calidad, así como la interrelación entre sí y con el negocio, y además aprenderás a gestionar globalmente el servicio a través de su ciclo de vida.

A través de la plataforma itenea podrás formarte a tu ritmo, sin plazos ni restricciones horarias. Únicamente deberás registrarte gratuitamente en la plataforma, si aún no lo has hecho, y matricularte en el curso. Allí tendrás a tu disposición contenidos para autoestudio y distintos tests de autoevaluación para poner a prueba lo aprendido.

ACTUALIZACIÓN: desde julio del 2017 itenea ha dejado de dar servicio

ATENCIÓN: Desde Noviembre de 2012, la entidad certificadora EXIN ofrece la posibilidad a todo aquél que lo desee de presentarse al examen online (que podrá hacer cuando y donde quiera) para obtener la certificación ITIL Foundation in IT Service Management.

Aterrizando los SLA

He decidido escribir un pequeño post acerca de nuestro querido Acuerdo del Nivel del Servicio o SLA para los amigos, gracias a que llevo varios días leyendo referencias acerca del mismo y del impacto que tiene lanzarlo en una organización.

El SLA ha de ser el documento donde se recojan las condiciones que gobiernen la relación entre cliente y proveedor de servicios tecnológicos. Este documento ha de estar vivo y debe estar sujeto a cambios a lo largo de su ciclo de vida, bien porque el cliente solicita mejores condiciones para cumplir con los objetivos de negocio o bien porque la organización de TI ve que no es capaz de llegar a las condiciones pactadas con los recursos de los que dispone (el caso de que el proveedor de TI proponga endurecer las condiciones no se suele dar con mucha frecuencia). Una vez pactado sirve de referencia contra lo que medirse y contra lo que poder determinar si el servicio es o no de buena calidad. El SLA debe incluir condiciones como el horario de servicio, el del soporte, el nivel de disponibilidad que se garantiza, los canales de acceso al soporte y a las extensiones del servicio, los horarios de las ventanas del servicio, carga esperada del servicio, tiempos de respuesta y de resolución en base a las prioridades.

El problema es que lanzarlo de esta forma no es tan fácil, a veces existen impedimentos como por ejemplo: el cliente no es capaz de cumplir su rol en la relación entre proveedor y cliente que gobierna el SLA, la falta de tiempo o de entendimiento, las herramientas de gestión con las que se cuenta no “œsacan” el % de disponibilidad global del servicio X, no es fácil definir la carga esperada del servicio que se puede soportar.

Según mi experiencia con departamentos de informática, únicamente con empezar a medir los tiempos de respuesta y de resolución en base a prioridades se logra un gran cambio de mentalidad. Los técnicos, gracias a la presión del cronómetro y del cumplimiento, se centran en solucionar aquellas incidencias o solicitudes que mayor impacto tienen en la actividad de la empresa y no dedicarse a aquellas que una vez resueltas alimentan el ego y pensamos por dentro “oye! Soy un hacha”¦” y esto es la bomba para los departamentos de informática porque se empiezan a concentrar en lo que verdaderamente importa, no en lo que a los técnicos más les gusta. Y ya, si una vez medidos, se cumplen, al resto de la organización le parecen correctos, y los publicamos, es un auténtico lujo! Luego solo nos queda mejorarlos continuamente, casi nada ;P

¿Alguien más quiere colaborar con su visión acerca del tema?

Nerea Molinero

ITIL v3.5?

La OGC (Oficina de Comercio del Gobierno Británico)ha revisado el contenido de los 5 libros de ITIL v3,5 publicados en 2007. Los motivos principales de la revisión de esta nueva edición 2011 (así le han llamado) han sido:

1. Eliminar inconsistencias que se dan entre los diferentes libros
2. Hacer inteligible el contenido del libro Estrategia del Servicio
3. Asegurar que el contenido es coherente con el glosario
4. Asegurar que todos los procesos se definen bajo la misma estructura de metas, objetivos, roles
5. Facilitar el entendimiento de las 5 publicaciones en general

Me parece perfecto, además era algo que, por lo visto la comunidad venía pidiendo.
Anda que no he pasado tiempo para entender Estrategia del Servicio a fondo, volviéndome loca viendo que los libros decían cosas diferentes acerca del mismo tema, intentando buscar el sentido de porqué el portfolio de servicios (Estrategia) se diseña en la fase de Diseño (así suena muy lógico pero cuando te sumerges en el mundo teórico de ITIL y lees esto, algunos planteamientos de base se desintegran y tienes que hacer más café). Según los resultados de una encuesta que ha realizado la OGC el 100% de los encuestados creen que los libros se entienden mejor. ALELUYA!

Lo que no me parece tan bien es que saquen esta nueva edición (que sale exclusivamente debido a fallos de la anterior) al mismo precio que los libros de 2007 para todo el mundo. Es decir, que como buenos ITILeros tenemos que comprar los 5 libros a un precio de 450€, nos los estudiamos con cierta dificultad y en 2011 tenemos que pagar otros 450€ para tener una versión que no tenga errores y sea más fácil de entender, ya está bien”¦

Por cierto, comentar también que esta nueva edición ha engordado un poquillo, lo cuenta estupendamente mi colega Joaquín Báñez en su interesantísimo blog ITIL-es del que soy fan “ITIL engorda“

¡Saludos a todos!

Consultoría ITSM ¿a ciegas?

¿Empezamos a ciegas los proyectos de consultoría? Yo creo que sí y explico por qué. Tomamos muchos datos al inicio para situar el escenario: datos de organización, de roles, datos técnicos, de operaciones”¦ Estos datos, por supuesto son necesarios, nos plantean el input del proyecto de forma objetiva, sabemos todo lo que hay que saber para empezar a trabajar en el proyecto de transformación”¦ espera ¿todo?

revisión ITSM¿Sabemos lo que piensa el personal acerca de este proyecto? ¿Sabemos quiénes lo ven como una oportunidad y quiénes como una amenaza? ¿Conocemos los miedos de las personas con respecto al cambio que se va a articular? ¿Conoce todo el personal los motivos del lanzamiento del proyecto?

Las personas pueden, tranquilamente y con una sonrisa en los labios, hacer que un proyecto de transformación se desvíe, desvirtúe o incluso hacer que fracase. Por mucho que nos empeñemos, si no tenemos a aquel agente del service desk borde de nuestra parte por poner un ejemplo, con toda seguridad nos dificultará la implantación, pondrá millones de pegas, nos mirará con desdén”¦ y al final, si tenemos suerte, puede que se dé por vencido y lo pase. Todo esto con la pérdida de tiempo o desviación correspondiente porque además, esta persona se ha encargado de poner mala fama al proyecto desde dentro: en el comedor, en la máquina de café y lamentablemente ha conseguido un pequeño ejército de máquinas de impedir que empiezan a renegar del proyecto guiados por su líder”¦ Claramente estoy exagerando, soy de Bilbao… pero seguro que a más de uno le suena familiar todo esto que estoy contando.

Todo es mucho más fácil, si al inicio del proyecto nos preocupamos por conocer las opiniones del personal para con el proyecto. Saber con qué aliados contamos y a quiénes nos tenemos que ganar. Conocer cuáles son los puntos fuertes y cuáles son los débiles, las fortalezas y las oportunidades. Comunicar debidamente el porqué del proyecto para hacer que todo el mundo se involucre”¦
Entiendo que muchos puedan pensar que es ciencia ficción pero realmente se puede hacer, doy fe, y además facilita una barbaridad el trabajo de implantación. ¿Alguien más se anima?

El misterio del Catálogo de Servicios

Es sorprendente que muchos Dptos. TI que gestionan sus servicios empleando procesos ITSM no dispongan de catálogo de servicios. Realmente decimos que estamos orientados a servicio y no disponemos de una única fuente de información acerca de lo que el cliente puede o no puede pedir. Sin un catálogo de servicios, los usuarios finales pueden pedir lo que deseen puesto que “œun servicio si no se especifica por adelantado queda a merced de quien lo recibe”. ¿Con qué cara le decimos a la persona que acaba de llamar que no le vamos a atender a su petición de que se le configure una impresora personal cuando no lo especificamos en ningún sitio?

El catálogo nos ayuda a reflexionar acerca de los servicios que prestamos, a definir un alcance, a realizar el caso de negocio ¿por qué los prestamos?, a definir los activos que gestionados correctamente proporcionan valor a nuestros usuarios, a saber cuánto de cada proceso de gestión consume cada servicio”¦ realmente el catálogo es necesario. El problema suele ser que nos da pereza enfrentarnos ante la construcción la obra del faraón, llevamos tanto tiempo dando soporte a tantas y tan variadas tecnologías que solamente con ponerse a pensar en él hace que lo vayamos dejando y dejando hasta que al final acaba por no hacerse.

Mi humilde consejo es que se empiece por algo, por definir en una simple Excel un catálogo de servicios interno básico sobre el que empezar a trabajar, definiendo pocos campos: nombre del servicio, extensiones del mismo, activos que intervienen, empresas y una pequeña referencia a las clausulas del SLA (tiempos de respuesta, de resolución frente a las diferentes prioridades). No será perfecto pero nos permitirá empezar a trabajar el proceso e ir mejorándolo continuamente. No olvidemos que es un elemento vivo por lo que ha de ser flexible, así que no dediquemos años en desarrollar el catálogo perfecto porque cuando terminemos probablemente estará obsoleto.

El segundo paso sería hacerlo público y orientarlo hacia el cliente y usuarios finales. El tercero y el más interesante según mi opinión sería lanzar el portfolio de servicios (haciendo gala de la flamante v3 de ITIL:)) definiendo no solo los servicios en activo sino aquellos que esperamos dar en un futuro y que están en fase de Business Case (el service pipeline) y documentando aquellos que se han retirado o que están en la fase de retirada para analizar con cuales de los nuevos servicios o modificaciones de los existentes cubrirán las necesidades de los que quitamos (retired services). Entiendo que llegar a este último paso implica un nivel alto de madurez pero creo que deberíamos tener presente cual es el camino a seguir.

Espero que mis pequeñas reflexiones acerca de este gran tema os sirvan de ayuda.

Nerea Molinero

Página 3 de 612345...Última »

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.

ACEPTAR
Aviso de cookies