Gestión de eventos simplificado

Gestión de Eventos es uno de los nuevos procesos en la última edición de ITIL. En mi opinión su función principal debe ser la de transformar datos (eventos) en información útil para poder anticiparse a males mayores. El libro de Operación del Servicio presenta un flujo muy detallado de las actividades, métodos y técnicas del proceso. Quizás demasiado detallado para organizaciones que no cuenten con una arquitectura TI excesivamente compleja. En el post de hoy me gustaría compartir un flujo más "simplificado" para las organizaciones más pequeñas.

Notificación de Evento

Las herramientas de monitorización reciben alertas de los distintos activos que forman la infraestructura TI, según los parámetros que se hayan establecido en dichas herramientas. Es decir si la parametrización de las herramientas de monitorización está configurada de tal forma que solo deben generar un evento cuando la capacidad de un disco duro alcance el 90%, no se tendrá ninguna “noticia” de este disco hasta que se alcance el umbral fijado. Debido a esto es muy importante que los “propietarios” o responsables de los distintos activos junto con el equipo de Gestión de Eventos establezcan dichos parámetros para que con la antelación suficiente los sistemas de monitorización avisen de un futuro problema.

Filtrado
La cantidad de eventos que se pueden llegar a generar de todos los activos monitorizados es un número lo suficientemente alto como para que sea necesario hacer un filtrado antes de pasar a su registro en la herramienta de ITSM. Que se realice este filtrado no quiere decir que solo se traspase información de caídas o interrupciones en los servicios de negocio. Si se filtra demasiado la Gestión de Eventos pierde su sentido puesto que no podrá alcanzar su objetivo de “ayudar” a otros procesos ITIL a anticiparse a futuros problemas. El filtrado debe ser consecuente con los objetivos que se busquen para la Gestión de Eventos.

Registro y clasificación
Una vez que se ha filtrado un evento y se decide traspasarlo a la herramienta de Gestión del Servicio ITSM, debe entrar en funcionamiento un mecanismo para que los datos se traspasen de forma automática. Este mecanismo debe realizar el registro del evento atendiendo a una serie de parámetros. Obtener una prioridad para el evento es un punto muy importante, puesto que esta será la que desencadene las siguientes acciones del proceso de Gestión de Eventos.

¿Tratamiento urgente?
Según la prioridad del evento y si este necesita un tratamiento urgente se debe traspasar toda la información necesaria para que el proceso de Gestión de Incidencias se haga cargo de la situación. En caso contrario el evento será almacenado con el objetivo de su posterior análisis.

Estudio de Tendencias
Con la periodicidad marcada por las políticas del proceso de Gestión de Eventos, el equipo de trabajo debe realizar un análisis de tendencias para detectar si eventos que aún no han tenido un impacto directo en la infraestructura pueden llegar a tenerlo en un futuro. Este estudio es fundamental a la hora de transformar una monitorización simplemente reactiva en un proceso proactivo.

¿Cuales son vuestras experiencias con la Gestión de Eventos?

Alberto Álvarez Álvarez

Entrevista con Oscar Corbelli

En el día de hoy tengo el inmenso placer de compartir con vosotros la entrevista que he realizado al "maestro" Oscar Corbelli. Recientemente galardonado con el premio al mejor instructor itSM 2011 y autor del libro "Las trampas de la integración", para mi Oscar es un referente y si alguno de vosotros aún no lo conoce mi consejo es que lo haga a través de su blog.

- ¿Qué beneficios crees que aporta la implantación de ITIL en una organización TI?
Todos los que tu imaginación pueda crear, sólo que depende de las personas. Podemos mencionar la mayor calidad en la entrega de servicios a través de claras definiciones de diseño; mejor soporte a usuarios a través de buenos procedimientos de incidencias y obviamente ITIL es la base para alinear y coordinar los servicios con los objetivos del cliente y crear valor agregado en los servicios. Esto se logrará siempre y cuando sucedan dos hechos anteriores: 

1. Compromiso total del negocio con el proyecto de implantación. 
2. Definir el nuevo marco cultural para que las personas decidan si se adhieren o no al mismo. (ver pág. 220 de “Las trampas de la integración") 

Dos temas que da para hablar varias horas, pero ineludibles para conseguir éxito en la implantación de ITIL.

- ¿Qué pasos se deben seguir para implantar ITIL con éxito?
No hay pasos predeterminados que deban tomarse como reglas, pero habrá aspectos en común en todas las organizaciones, como por ejemplo los mencionados en el punto anterior, que serán el inicio de un proyecto, con un responsable y que habrá que gestionar. Quizá la cuestión más difícil es decidir por dónde iniciar, es decir cuáles procesos comenzar a implantar. Las recomendaciones aquí será identificar dónde están los “cuellos de botella” que impiden mejorar. Lo más probable es que el día a día sea el inicio, es decir con todas las actividades relacionadas a dar soporte y resolución de problemas de usuarios, pero no debe tomarse como excusa para no hacer las otras acciones. Lo que quiero decir es que siempre deberá tenerse como objetivo implantar todas las fases del ciclo de vida del servicio.

Es imposible implantar ITIL con éxito si la dirección superior (TI y Negocio) no tienen la formación básica de la gestión basada en el ciclo de vida. Los dirigentes del negocio deben saber que la gestión de servicios es una actividad de su negocio y las inversiones TI son decisiones de negocio.

- ¿Se puede implantar ITIL en cualquier tamaño de organización, PYME, gran empresa, Administración Pública...?
Si, sin ninguna duda. La diferencia estará en los tiempos necesarios para explicar y convencer. Es importante contestarse la pregunta ¿qué quiere el CEO que haga su CIO? Y luego considerar con quiénes cuentas. No puedes desconocer que siempre habrá algunos perdedores. 

Si piensas en la implantación en una PYME el consejo es considerar implantar 5 procesos (Estrategia, Diseño, Transición, Operación y Mejora continua) que tendrán actividades (subprocesos) en cada uno de ellos; de esta forma tendrás el foco completo del ciclo de vida.

- Respecto a la última edición de ITIL, la 2011, ¿qué parte del ciclo de vida crees que es más crítico para una organización (Estrategia, Diseño, Transición, Operación o Mejora Continua)?
Mi visión de criticidad en ITIL es que no podemos enfocarnos o dar prioridad a una o dos fases, sino a todas ellas. Fíjate que se llama “ciclo de vida” del servicio. ¿Dejarías de atender a tu hijo durante la etapa que va de la pubertad a la adolescencia? ¿Dejarías la educación de tu hijo sólo a cargo de la escuela? 

- ¿Cómo ves el futuro de ITIL?
La nueva edición 2011 ha mejorado mucho y por fin a nucleado todas las opiniones de la industria, mucho más cerca del negocio. Fíjate que ahora no sólo hablamos de valor agregado sino también de valor realizado. Es decir que TI está llegando hasta el consumidor de los productos o servicios de su cliente. El futuro será un CIO transformador del negocio de su cliente, por lo que la gestión se los servicios será una herramienta más para esa integración. El futuro de la biblioteca será desarrollar con más amplitud las acciones que consigan la integración. (quizás ayude lo que he planteado en “Las trampas de la integración"). 

ITIL deberá asegurar que TI comprenda el mercado y al negocio y facilitar el cambio organizacional. Este último punto está presente en el libro de Transición, pero habrá que mejorarlo en las siguientes ediciones.

Lo que me preocupa es su implantación en España; aun creemos que todo es muy difícil, que cuesta mucho, que la gente, etc. etc.; seguimos dando excusas basados en esquemas socio-culturales, cuando en realidad el problema es el liderazgo.

Oscar, gracias por tu colaboración.

Alberto Álvarez Álvarez

Incrementar la solución en el primer contacto

Que gran objetivo, ¿verdad? Cuando he tenido que realizar las funciones de usuario final "enfrentándome" a un Service Desk siempre tengo la sensación de que los agentes tienen el trabajo más desagradecido de toda la organización TI. Quiero tener una solución inmediata y a veces se me olvida lo difícil y estresante que es su trabajo. Por lo general suele ser el peor remunerado y es el grupo donde es más factible realizar mediciones de todo tipo para evaluar su desempeño: tiempos de llamada, número de llamadas atendidas por agente, tiempo de timbre, tiempos de desconexión,... Por otra parte he tenido la suerte de poder realizar "escuchas" en diferentes proyectos y la verdad es que habitualmente me reconforta ver la profesionalidad con la que los agentes desarrollan su trabajo. Bien por ellos!

Incrementar el índice de solución en el primer contacto es un requerimiento habitual del negocio y de los propios usuarios finales, conseguirlo no es tarea fácil pero PODEMOS!! En mi opinión hay que potenciar los siguientes aspectos:

• Procedimientos de solución. Todos, repito, todos los grupos de la organización deben facilitar documentos claros y concisos para que los agentes de Service Desk puedan aplicar soluciones inmediatas. Una o dos páginas puede ser un documento "utilizable" por un agente.

• Formación continua. Los cambios constantes en la infraestructura TI de cualquier organización deben ser dados a conocer incluso de forma previa a que sucedan al Service Desk.

• Automatización de soluciones. La creación de herramientas internas para dar solución a incidencias del estilo desbloqueo de usuarios o eliminar trabajos en la cola de impresión facilitan y disminuyen considerablemente los tiempos de solución.

• Procedimientos diagnóstico. Es muy difícil aplicar una solución válida si no se sabe cual es el problema.

• Divide y vencerás. Aunque pueda parecer un contrasentido dividir el Service Desk en pequeños grupos de conocimiento redunda en un incremento de la solución en el primer contacto. Eso si tiene sus desventajas y es necesario evaluar detenidamente este punto antes de llevarlo a la práctica.

Cualquier tiempo que se dedique a mejorar el funcionamiento del Service Desk tendrá un retorno inmediato: aumento de la satisfacción del usuario. 

¿Estáis de acuerdo?

¿Que soléis hacer en vuestras organizaciones?

Alberto Álvarez Álvarez

Categorización de incidencias

"La mejor estructura no garantizará los resultados ni el rendimiento. Pero la estructura equivocada es una garantía de fracaso."

Peter Drucker

Cuando el "padre del management" pronunció esta frase seguro que no estaba pensando ni mucho menos en como se deben categorizar las incidencias, pero creo que es muy importante tenerla presente a la hora de crear una estructura para clasificar las incidencias. No es lo mismo tener datos que tener información y agrupar de forma correcta las incidencias es fundamental para obtener información útil y no simples datos estadísticos. Vamos por partes.

En primer lugar, en el apartado del libro de Operación de Servicio dedicado a la   "Categorización de las incidencias" se enumeran una serie de pasos "para alcanzar un conjunto correcto y completo de categorías...". En mi opinión falta el paso más importante de todos hablar con el negocio. La organización TI esta al servicio del negocio, y por lo tanto hay que tener muy en cuenta su opinión a este respecto. Un informe de incidencias para un CEO o Director General que refleje que ha habido X número de incidencias de categoría Hardware/Servidor/Placa de Memoria/Tarjeta probablemente no le diga nada, sin embargo si el informe hace referencia al número de incidencias que ha sufrido el Servicio de Negocio Y le será de mucha más utilidad.

Por otra parte además de tener una estructura coherente con los objetivos del negocio, es muy importante que la información sea fiable. Habitualmente la categorización de una incidencia forma parte de la actividad inicial de registro, en el caso de que la solución corra a cargo de una segunda o tercera linea es casi  seguro que la categoría variará. En la última edición de ITIL se recomienda utilizar una categoría de cierre lo cual me parece muy acertado pero discrepo en que ésta tenga que ser revisada por el Centro de Atención al Usuario. Creo que es más apropiado que la revisión se haga por parte del grupo que ha solucionado la incidencia que será el que tenga toda la información necesaria para realizar una categorización correcta.

Hay organizaciones que disponen de distintos tipos de categorización (inicial, final, operativa...). Mi recomendación es que se utilice única y exclusivamente aquella(s) que suponga(n) un beneficio para el negocio. En la simpleza está el éxito.

¿Que opináis?

También podéis dejar vuestra opinión en el grupo de LinkedIn itSMF en español.

Alberto Álvarez Álvarez

Organizar una petición.

A día de hoy todavía existen organizaciones en las que una petición de servicio tiene el mismo tratamiento que una incidencia. Para mí esto es un error de bulto y según recomienda el conjunto de mejores prácticas, ITIL, estas dos entidades han de ser gobernadas por procesos independientes. Las actividades reflejadas para el proceso de Gestión de Peticiones en el libro de Operación del servicio, me parecen poco detalladas y voy a intentar aportar mi granito de arena.

En la edición en español la primera actividad tiene un título no muy afortunado, Selección de menús, pero esto es lo de menos. Estoy totalmente de acuerdo en que una petición de servicio es un proceso muy adecuado para poner en producción un interfaz web estilo "carrito de la compra" que de la oportunidad al usuario final de realizar su solicitud de forma on-line. Por favor, hay que erradicar definitivamente el formulario en papel.

La siguiente actividad, Aprobación Financiera. Desde mi punto de vista, tal y como se puede leer entre lineas, es una actividad que no debe estar asociada a cada una de las peticiones. Lo aconsejable es marcar unas limitaciones económicas y que solo en caso de rebasar estas, se pida aprobación financiera. Hay algo en esta actividad que yo asociaría a la anterior y es precisamente el informar al usuario de cual es el coste de la petición y si es necesaria una autorización previa.

Otra aprobación. Si se necesitan tantas aprobaciones ¿quizás estamos hablando de un cambio?.

Cumplimiento. Apartados como este son los que me animan a compartir mis experiencias.
Para llevar a cabo una petición de servicio es bastante habitual que intervengan distintos grupos o equipos de trabajo, cada uno puede llevar a cabo distintas tareas dentro de la misma solicitud. Trabajar en base a tareas es muy recomendable por varias razones:

• En múltiples ocasiones hay tareas que se pueden llevar a cabo de forma paralela. Si se trata como una incidencia es muy difícil por no decir imposible que se puedan ejecutar distintas tareas al mismo tiempo.
• Trabajar en base a tareas permite establecer un orden lógico, por ejemplo antes de dar de alta un usuario en el sistema de correo electrónico hay que comprobar que existe en el directorio activo.
• Si se utilizan tareas será mucho más sencillo obtener una planificación e incluso una industrialización del proceso.
• Se facilita la trazabilidad de la ejecución.

Si la organización adopta esta forma de trabajar mediante tareas, es muy importante que se tenga en cuenta como un factor más a la hora de implantar una nueva herramienta de gestión de servicio.

La última actividad, Cierre. Ayuda a tú Service Desk, implementa un buen procedimiento que permita al usuario cerrar sus propias peticiones de forma automática.

Y en tú organización, ¿incidencias y peticiones se tratan de la misma forma?

Alberto Álvarez Álvarez