Midiendo ITIL

“Midiendo
ITIL®”

Roberto
Sánchez

Service
Delivery
Manager

“ITIL®
is
a
registered
trade
mark
of
the
Cabinet
Oﬃce”

Agenda

•  ¿Por
qué
debemos
medir
ITIL®?

•  Beneﬁcios
de
la
medición

•  Riesgos
de
no
medir

•  Midiendo
para
la
mejora
con@nua

•  Ejemplos
básicos
de
medidas
para
procesos

•  Conclusiones

¿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.

Beneﬁcios
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?

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
deﬁne
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

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)

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

Especiﬁcación
trabajo
equivocado.
El
obje@vo
de
Service
Desk
es
ayudar
a
restaurar
el
servicio

JusOﬁcació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

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
Especiﬁcació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

JusOﬁcació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

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.

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

Especiﬁcació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

JusOﬁcació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

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.

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

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

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@ﬁcar
qué
se
quiere
medir
para
deﬁnir
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.

Roberto
Sánchez

Service
Delivery
Manager

roberto_sanchez@inteli.com.mx

@
rsanchez_inteli

linkedin.com/in/
rsanchezglz

Midiendo ITIL

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Midiendo ITIL (20)

Más de Inteli (9)

Último (20)

Midiendo ITIL