“Midiendo ITIL®” Roberto Sánchez

Service Delivery Manager

“ITIL® is a registered trade mark of the Cabinet Office” “The Swirl logo™ is a registered trade mark of the Cabinet Office”

Agenda

• ¿Por qué debemos medir ITIL®?

• Beneficios de la medición

• Riesgos de no medir

• Midiendo para la mejora continua

• Ejemplos básicos de medidas para procesos

• Conclusiones

• No se puede controlar aquello que no se puede medir

• Medir en ITIL Permite:

– Validar - Decisiones anteriores

– Dirigir – Establecer la dirección de las acciones

– Justificar – El curso de acciones necesarias

– Intervenir - Identificar un punto de intervención como las posteriores modificaciones y acciones correctivas.

¿Por qué medir?

• Los procesos de ITIL miden:

– Cumplimiento - ¿Lo estamos haciendo?

– Calidad - ¿Qué tan bien lo estamos haciendo?

– Rendimiento (performance) - ¿Qué tan rápido o lento lo estamos haciendo?

– Costo (valor) – ¿Lo que hacemos hace la diferencia?

Beneficios de Medir ITIL

Midiendo la Mejora Continua Métricas en los Procesos

• Las métricas son un sistema de parámetros o forma de evaluación cuantitativa de un proceso que se va a medir.

• La métrica define qué medir y están especializadas en un tema o dominio determinado.

Objetivos

CSF

KPI

Métricas

Medición

Mejorar la calidad de los servicios de TI

Reducir el número de incidentes a Y

y el tiempo de solución en X tiempo en tres meses

Número de incidentes actuales

Número de incidentes en los siguientes tres meses

Tiempo promedio de solución actual

Tiempo promedio de solución en los siguientes tres meses

Incrementar la adquisición y uso de los servicios de los

clientes de la organización

Número de incidentes recibidos

Número de incidentes resueltos en tiempo vs recibidos

Tiempo promedio de solución

CSI

• El proceso que tiene mayor impacto en la percepción de la Calidad de los Servicios que proveen las Organizaciones de TI es: Gestión de Incidentes.

• Qué se puede medir en la Gestión de Incidentes

– La Satisfacción del Cliente, (rapidez en la resolución de los incidentes, reducción en el tiempo de espera en el Service Desk)

– La Calidad de los Servicios de TI (reduciendo la no disponibilidad al resolver los incidentes)

– La productividad del Negocio y de TI (resolviendo los incidentes en la primera línea de soporte)

Calidad y Satisfacción al Cliente

Ejemplo: Métrica para Service Desk

Métrica Porcentaje de llamadas escaladas incorrectamente

Descripción Se mide cuando una llamada es reasignada debido a que fue incorrectamente asignada.

Especificación Porcentaje de llamadas que son escaladas al grupo de trabajo equivocado.

Justificación

El objetivo de Service Desk es ayudar a restaurar el servicio tan rápido como sea posible, la asignación incorrecta retrasa esta medición.

Audiencia Dueño del Service Desk, IT Management, Gestor de Niveles de Servicio, Miembros del Equipo.

Restricciones No aplica

Valor objetivo 5 Valor Riesgo 15 Valores Posibles 0 a 100

Medición Número total de llamadas recibidas

Medición Número de llamadas con más de un escalamiento

© Copyright 2002 Inteli S.C

Ejemplo: Métrica para Gestión de Incidentes

Métrica Porcentaje de incidentes resueltos por el primer nivel de soporte

Descripción Cuántos incidentes no han requerido del escalamiento al segundo nivel de soporte

Especificación Un recuento de los incidentes que no requirieron de escalamiento

Justificación

Esta es una medida de unas cuantas cosas. Si el Service Desk tiene una buena base de datos de errores conocidos proveída por Gestión de Problemas , el número de incidentes resueltos por la primera línea de soporte debe incrementarse

Audiencia Dueño del proceso, Administración de TI, Administrador de niveles de servicio, Miembros del equipo,

Restricciones

Si el proceso de Gestión de Problemas es exitoso en la eliminación de la causa raíz, la parte de Incidentes resueltos por la primera línea disminuirá y en consecuencia el número de incidentes resueltos por la primera línea de soporte también disminuirá

Valor objetivo 85 Valor Riesgo < 65 Valores 0 a 100

Medición Numero Total de Incidentes registrados

Medición Número de Incidentes que no fueron escalados por el primer nivel de Soporte

• Porcentaje de incidentes resueltos en la primera línea de soporte.

• Porcentaje de incidentes resueltos dentro de los SLA

• Reducción en la indisponibilidad de los servicios causados por incidentes

• Reducción en el porcentaje del tiempo promedio para resolver los incidentes.

• Costo promedio por incidente.

• Porcentaje de incidentes reabiertos

• Número y porcentaje de incidentes mal asignados.

Métricas de la Gestión de Incidentes

Ejemplo: Métrica para Gestión de Cambios

Métrica Porcentaje de Cambios completados en tiempo.

Descripción Todos los Cambios que han sido completados en tiempo. Si todavía están abiertos después de este tiempo también se deben considerar.

Especificación

Los retrasos puede ser causados por buenas razones: Si el porcentaje de cambios fallidos es bajo, entonces un alto valor aquí podría estar bien por lo que debe ser una prioridad baja la mejora.

Justificación Si los Cambios son constantemente completados tarde, esto muestra un pobre control de Cambios y un incremento en los riesgos de interrumpir al negocio.

Audiencia Dueño del proceso, Administrador de TI, Gestor de Niveles de Servicio, Clientes del Negocio y Miembros del equipo.

Restricciones Ninguna

Valor objetivo 95

Valor Riesgo 90 Posibles Valores 0 a 100

Medición Número total de Cambios registrados y completados

Medición Número de Cambios Completados en tiempo

• Porcentaje de cambios no autorizados detectados

• Porcentaje de cambios implementados en tiempo

• Porcentaje de cambios fallidos

• Porcentaje de los cambios a los que se les ha aplicado “back out”

• Porcentaje de cambios que han impactado los Servicios “Core” y la disponibilidad proporcionada en los SLA.

• Porcentaje de cambios ejecutados en tiempo y costos previstos.

Métricas para la Gestión de Cambios

Métricas de Gestión de Niveles de Servicio

• Número de servicios cubiertos por los SLA.

• Tiempo que toma responder e implementar las solicitudes de SLA

• Número de revisiones de los SLA completadas en tiempo

• Número de SLA pendientes de renegociación anual

• Número de SLA que requieren cambios correctivos

• Número de OLA y UC

• Número y severidad del incumplimiento del SLA

• Número de revisiones y seguimiento de todos los incumplimientos de los SLA, OLA y UC

Métricas de Gestión de Niveles de Servicio

• Número de objetivos omitidos en el SLA

• Número de objetivos amenazados en el SLA

• Número de acuerdos que cuentan con incumplimiento al SLA

• Número total y aumento del porcentaje de SLA documentados

• Número de Acuerdo de Nivel de Servicio pactados

• Costos asociados con la provisión del servicio

• Tiempo consumido en el desarrollo y negociación de los SLA

• Número de Reuniones para la revisión del servicio

• Si no se cuenta con mediciones es difícil iniciar un proceso de mejora de los servicios y procesos de TI.

• Es importante identificar qué se quiere medir para definir las métricas y ver si hay elementos para la medición.

• Conforme maduren los procesos es necesario establecer nuevas métricas y hacer la interpretación correcta de la información.

• Lo más valioso para medir es la fuente de información, que está en los procesos.

Conclusión

@

linkedin.com/in/

Roberto Sánchez Service Delivery Manager

roberto_sanchez@inteli.com.mx

rsanchez_inteli

rsanchezglz