Es tan sencillo como montar un backlog de historias de mejora, historias que salen de la “A” del PDCA de cada proceso. Habitualmente el rol de Service Manager cubre el rol de Product Owner y decide qué historias de mejora priorizar. El equipo (habitualmente operaciones y service desk) decide qué historias abordar en el sprint, “P” y durante el sprint se trabaja en resolución de las mismas, “D”. En la demo del sprint se muestra el trabajo realizado y el análisis de los indicadores, “C” para que se puedan lanzar nuevas historias de mejora, “A” y completamos una vez más el ciclo. De esta forma conseguimos también que las mejoras se pongan en producción lo antes posible para detectar rápidamente (siguiente sprint) los bugs que pudiesen surgir (p. ej. Falta definir un criterio más claro para definir los cambios pre-aprobados puesto que hay cierta confusión cuando se trata de bla bla…). Las historias no solo contemplan mejoras de proceso, también se incluyen para revisar documentación, cambiar el alcance, planificar la auditoria interna y demás tareas que no pertenecen a ningún proceso concreto.

Dinámico, ágil y sencillo, características que se agradecen para los proyectos de certificación.

Nerea Molinero

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.

Esperamos que el curso sea de tu interés. Puedes matricularte en él aquí: http://www.itenea.com/

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 “yes! 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

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!

Nerea Molinero

¿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?

Nerea Molinero

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

Curioso pero no deja de ser una gran idea  

Nerea Molinero

Dirigido a:

El curso está dirigido tanto al personal de IT relacionado con la prestación de servicios (directivos, mandos intermedios, personal del Service Desk, etc), como a personal de las áreas de negocio o gerencia que quiere mejorar su comprensión del mundo IT y la relación entre ambas partes.

Precio

345 € (examen de certificación incluido)

Así que le dimos una vuelta a todo el contenido del curso, nada de Power Point ni de proyector (salvo para mostrarles 2 ó 3 vídeos irónicos sobre el mundo TI), y todavía más learning by doing del habitual. Cuando el objetivo es conseguir una certificación oficial hay que ser más estricto con la teoría, pero en este caso pudimos permitirnos basar todo el curso en la simulación Control-IT,  juegos, preguntas y discusiones.  Que aprendan, le pierdan el miedo a ITIL, y compartan con los demás los puntos negros que perciben en el departamento.

La experiencia fue interesante. Al final prácticamente nos faltó tiempo para las discusiones generadas, la gente pudo exponer en voz alta sus preocupaciones sobre el estado actual de su departamento, y los principales obstáculos que veían para la mejora – como siempre, restricciones humanas más que técnicas. Probablemente con 3-4 cambios sencillos podrían obtener bastantes mejoras, la famosa regla del 80/20. Ahora sólo falta que pongan manos a la obra.

Teresa Oliver

Eskerrik asko a todos por venir!

Nerea Molinero