midiendo itil® - software itsm de control de … · • el proceso que tiene mayor impacto en la...
TRANSCRIPT
“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
rsanchez_inteli
rsanchezglz