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.

1. “Midiendo
ITIL®”
Roberto
Sánchez
Service
Delivery
Manager
“ITIL®
is
a
registered
trade
mark
of
the
Cabinet
Office”

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. ¿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. 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. 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. 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. 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. 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. 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. 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 Ninguna
Valor
objeOvo
Valor
Riesgo
90
Posibles
Valores
0
a
100
95
Medición Número
total
de
Cambios
registrados
y
completados
Medición Número
de
Cambios
Completados
en
@empo

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. 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. 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. 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. Roberto
Sánchez
Service
Delivery
Manager
roberto_sanchez@inteli.com.mx
@
rsanchez_inteli
linkedin.com/in/
rsanchezglz