Midiendo ITIL

1.399 visualizaciones

Publicado el

La importancia y la necesidad de medir los procesos de ITIL®. De la teoría a la práctica. Los ejecutivos de TI tienen la necesidad de ofrecer beneficios tangibles y mostrar, en números, su contribución a los objetivos de negocio y a la alineación estratégica. Para ello, la clave está en hacer de TI un activo estratégico y considerar la implementación de ITIL® como una inversión que puede mejorar la gestión de los servicios de TI.

Publicado en: Tecnología
0 comentarios
4 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
1.399
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
53
Comentarios
0
Recomendaciones
4
Insertados 0
No insertados

No hay notas en la diapositiva.

Midiendo ITIL

  1. 1. “Midiendo  ITIL®”   Roberto  Sánchez      Service  Delivery  Manager  “ITIL®  is  a  registered  trade  mark  of  the  Cabinet  Office”  
  2. 2. Agenda  •  ¿Por  qué  debemos  medir  ITIL®?    •  Beneficios  de  la  medición    •  Riesgos  de  no  medir    •  Midiendo  para  la  mejora  con@nua    •  Ejemplos  básicos  de  medidas  para  procesos  •  Conclusiones  
  3. 3. ¿Por  qué  medir?  •  No  se  puede  controlar  aquello  que  no  se  puede  medir  •  Medir  en  ITIL  Permite:   –  Validar  .  Dicisiones  anteriores   –  Dirigir  –  Establecer  la  dirección  de  las  acciones     –  Jus@ficar  –  El  curso  de  acciones  necesarias   –  Intervernir    -­‐  Iden@ficar  un  punto  de  intervención  como  las   posteriores  modificaciones  y  acciones  correc@vas.  
  4. 4. Beneficios  de  Medir  ITIL  •  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?  
  5. 5. CSI Midiendo  la  Mejora  ConOnua   Métricas  en  los  Procesos  •  Las  métricas  son  un  sistema  de  parámetros  o  forma  de  evaluación    cuan@ta@va  de   un  proceso  que  se  va  a  medir.  •  La  métrica  define  qué  medir  y  están  especializadas  en  un  tema  o  dominio   determinado.   Incrementar la adquisición y uso de los servicios de los Obje@vos   clientes de la organización CSF   Mejorar la calidad de los servicios de TI Reducir el número de incidentes a Y KPI   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 Métricas   Tiempo promedio de solución actual Tiempo promedio de solución en los siguientes tres meses Número de incidentes recibidos Número de incidentes resueltos en tiempo vs recibidos Medición   Tiempo promedio de solución
  6. 6. Calidad  y  SaOsfacción  al  Cliente  •  El  proceso  que  @ene  mayor  impacto  en  la  percepción  de  la   Calidad  de  los  Servicios  que  proveen  las  Organizaciones  de  TI   es:  Ges@ón  de  Incidentes.  •  Qué  se  puede  medir  en  la  Ges@ón  de  Incidentes     –  La  SaOsfacción  del  Cliente,  (rápidez  en  la  resolución  de  los   incidentes,  reducción  en  el  @empo  de  espera  en  el  Servcie  Desk)   –  La  Calidad  de  los  Servicios  de  TI  (reduciendo  la  no   disponibilidad  al  resolver  los  incidentes)   –  La  producOvidad    del  Negocio  y  de  TI  (resolviendo  los   incidentes  en  la  primera  línea  de  soporte)  
  7. 7. Ejemplo:  Métrica  para  Service  Desk   Métrica Porcentaje  de  llamadas  escaladas  incorrectamente Se  mide  cuando  una  llamada  es  reasignada  debido  a  que  fue   Descripción incorrectamente  asignada. Porcentaje  de  llamadas  que  son  escaladas  al    grupo  de   Especificación trabajo  equivocado. El  obje@vo  de  Service  Desk  es  ayudar  a  restaurar  el  servicio   JusOficación tan  rápido  como  sea  posible,  la  asignación  incorrecta  retrasa   esta  medición. Dueño  del  Service  Desk,  IT  Management,  Gestor  de  Niveles   Audiencia de  Servicio,  Miembros  del  Equipo. Restricciones No  aplica Valor  objeOvo  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
  8. 8. Ejemplo:  Métrica  para  GesOón  de  Incidentes   Métrica Porcentaje  de  incidentes  resueltos  por  el  primer  nivel  de  soporte Cuántos  incidentes  no  han  requerido  del  escalamiento  al  segundo  nivel  de   Descripción soporte Especificación Un  recuento  de  los  incidentes  que  no  requirieron  de  escalamiento Esta  es  una  medida  de  unas  cuantas  cosas.  Si  el  Service  Desk  @ene  una   buena  base  de  datos  de  errores  conocidos  proveída  por  Ges@ón  de   JusOficación Problemas  ,  el  número  de  incidentes  resueltos  por  la  primera  línea  de   soporte  debe  incrementarse Dueño  del  proceso,  Administración  de  TI,  Administrador  de  niveles  de   Audiencia servicio,  Miembros  del  equipo,   Si  el  proceso  de  Ges@ó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   Restricciones en  consecuencia  el  número  de  incidentes  resueltos  por  la  primera  línea  de   soporte  también  disminuirá Valor  objeOvo  85   Valor  Riesgo  <  65   Valores  0  a  100   Medición Numero  Total  de  Incidentes  registrados Número  de  Incidentes  que  no  fueron  escalados  por  el  primer  nivel  de   Medición Soporte © Copyright 2002 Inteli S.C
  9. 9. Métricas  de  la  GesOón  de  Incidentes  •  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  •  Reduccción  en  el  porcentaje  del  @empo  promedio  para   resolver  los  incidentes.  •  Costo  promedio  por  incidente.  •  Porcentaje  de  incidentes  reabiertos  •  Número  y  porcentaje  de  incidentes  mal  asignados.  
  10. 10. Ejemplo:  Métrica  para  GesOón  de  Cambios  Métrica Porcentaje  de  Cambios  completados  en  @empo. Todos  los  Cambios  que  han  sido  completados  en  @empo.  Si  todavía  están  abiertos  Descripción después  de  este  @empo  también  se  deben  considerar. Los  retrasos  puede  ser  causados  por  buenas  razones:  Si  el  porcentaje  de  cambios  Especificación fallidos  es  bajo,  entonces  un  alto  valor  aquí  podría  estar  bien  por  lo  que  debe  ser  una   prioridad  baja  la  mejora. Si  los  Cambios  son  constantemente  completados  tarde,  esto  muestra  un  pobre  JusOficación control  de  Cambios  y  un  incremento  en  los  riesgos  de  interrumpir  al  negocio.   Dueño  del  proceso,  Administrador  de  TI,  Gestor  de  Niveles  de  Servicio,  Clientes  del  Audiencia Negocio  y  Miembros  del  equipo.Restricciones NingunaValor  objeOvo   Valor  Riesgo  90   Posibles  Valores    0  a  100  95  Medición Número  total  de  Cambios  registrados  y  completadosMedición Número  de  Cambios  Completados  en  @empo
  11. 11. Métricas  para  la  GesOón  de  Cambios  •  Porcentaje  de  cambios  no  autorizados  detectados  •  Porcentaje  de  cambios  implementados  en  @empo  •  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  @empo  y  costos   previstos.  
  12. 12. Métricas  de  GesOó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  @empo  •  Número  de  SLA  pendientes  de  renegociación  anual  •  Número  de  SLA  que  requieren  cambios  correc@vos  •  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  
  13. 13. Métricas  de  GesOón  de  Niveles  de  Servicio  •  Número  de  obje@vos  omi@dos  en  el  SLA  •  Número  de  obje@vos  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  
  14. 14. Conclusión  •  Si  no  se  cuenta  con  mediciones  es  didcil  iniciar  un  proceso  de   mejora  de  los  servicios  y  procesos  de  TI.  •  Es  importante  iden@ficar  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.  
  15. 15. Roberto  Sánchez  Service  Delivery  Manager    roberto_sanchez@inteli.com.mx     @   rsanchez_inteli   linkedin.com/in/  rsanchezglz  

×