Informe de la práctica de

Incidentes y Solicitudes de
servicio
Agenda

▪ Resultados de evaluación ▪ Factores de éxito

o Objetivo ▪ Siguientes pasos
o Estrategia de análisis
o Conclusiones / Recomendaciones

▪ Propuesta de la práctica
o Roles y responsabilidades de la práctica
o Proceso de la práctica (AS IS / TO BE)
o Datos fundamentales
Resultados de evaluación
(Assessment)
Objetivos

➢ Conocer la situación actual de la operación

comparada con los marcos de referencia (ITIL, Cobit)
sobre la ejecución de las prácticas de Incidentes y
Solicitudes de servicio.

➢ Presentar recomendaciones sustentadas en el

muestreo realizado en función al marco de referencia
de mejores prácticas, ITIL.
Estrategia de análisis
Puntos
Puntuaje % GAP
Obtenidos
21.50 40 46%
Se basó en el muestreo de entrevistas a fin de valorar
el nivel de compresión sobre la ejecución de
actividades que dan respuesta a las prácticas sobre la Mesa de servicio
7.0
gestión de incidentes y solicitudes de servicio. 6.0
Registro, clasificación y
Mejora Continua 5.0 priorización
4.0
3.0
Tema Puntuaje Puntos
obtenidos 2.0

Mesa de servicio 4.00 1.83 1.0

Monitorear el ciclo de vida el Verificar, aprobar y atender las
Registro, clasificación y priorización 10.00 6.33 incidente o solicitud
0.0
solicitudes
Verificar, aprobar y atender las solicitudes 6.00 1.50
Diagnosticar, escalar y resolver incidente 7.00 4.67
Resolver incidentes mayores 4.00 2.67
Cerrar solicitudes e incidentes 3.00 2.17
Diagnosticar, escalar y resolver
Monitorear el ciclo de vida, el incidente o solicitud 5.00 2.33 Cerrar solicitudes e incidentes
incidente
Mejora Continua 1.00 0.00
Resolver incidentes mayores
Nivel de Capacidad

Se concluye, que
actualmente las prácticas
de Gestión de Incidentes
y Solicitudes de servicio,
se logran más o menos a
través de actividades no
muy organizadas y en
algunos casos
incompletas.
Recomendaciones
Tema Conclusiones
Mesa de ▪ Se identificó que no existe formalización de quienes
servicio conforman la Mesa de servicio y como se relacionan con esta
las áreas especializadas.
▪ Existe desconocimiento por parte de las áreas de negocio, con
respecto al catálogo de servicios proporcionados por la
dirección de Tecnología
Registro, ▪ Las peticiones cuando son realizadas vía telefónica o
clasificación presencial no siempre son registradas, ya sea por el usuario o
y ingeniero que atiende.
priorización ▪ Se identificó que no existe un estándar para recabar
información sobre las peticiones de la comunidad usuaria, por
ende llega a generarse confusión al momento de tipificar la
solicitud.
▪ El campo de categorización, no está siendo documentada
como parte de la práctica.
▪ La tabla de prioridades y SLA´s se encuentra desactualizada y
es poco conocida por el equipo de trabajo.
* Alcance de Enevasys
Recomendaciones
• Formalizar y comunicar internamente el equipo que
conformará la Mesa de Servicio.
• Definir roles y responsabilidades de los grupos
resolutores (equipos de soporte especializado) y su
relación con la Mesa de Servicio.
• Generar campaña de comunicación con las áreas de
negocio sobre los propósitos de la Mesa de Servicio
• Desarrollar y formalizar el catálogo de servicios de
vista a negocio dentro de la organización
• Actualizar las prioridades, las cuales deben ser
definidas y acordadas desde la perspectiva del negocio.
• Generar nueva propuesta de SLA´s tomando como
base la actualización de la tabla de prioridades.
• Actualizar categorizaciones de operación con base al
catálogo de servicios IT.
• Incluir dentro del proceso los conceptos base
declarados por el marco de ITIL de categorización,
registro y priorización *
• Agregar los campos de categorización y SLAs dentro
de la JSM *
Recomendaciones * Alcance de Enevasys

Tema Conclusiones Recomendaciones

Verificar, ▪ Al no existir un catálogo de servicios documentado y • Construir y mantener un catálogo de servicios IT
aprobar y formalizado, tampoco existe un catálogo de solicitudes de • Generar acuerdos de niveles de operación entre los
atender las servicio y modelos de autoayuda para el usuario final. grupos resolutores
solicitudes ▪ Se cuenta con un proceso de gestión de acceso, el cual es • Incluir, dentro de la práctica de gestión de solicitudes,
gestionado por el área de Calidad. el tratamiento de gestión de acceso *
▪ Las escalaciones funcionales entre los equipos se realiza • Segmentar el catálogo de servicios para
bajo la experiencia en la operación por parte del personal, transformarlos en plantillas de servicio para la gestión
sin incluir tiempos para estas escalaciones. dentro de JSM *
▪ Las escalaciones jerárquicas solo aplican cuando los SLA´s
están por incumplir, haciendo partícipe a las gerencias.

Diagnosticar, ▪ Se identifica que no existe estandarización sobre la
escalar y documentación técnica, incluyendo su centralización y
resolver disponibilidad para toda el área de Tecnología.
incidente ▪ El nivel de detalle de documentación de los tickets, queda a
criterio del ingeniero que atiende.
▪ Las escalaciones entre los grupos resolutores se realiza
conforme a los criterios del ingeniero que atiende, se identifica
que no existen acuerdos de operación para garantizar el
cumplimiento de los SLA, esto incluyendo la gestión con
proveedores.
• Definir y convenir acuerdos de operación (OLA) entre
los grupos resolutores y la Mesa de Servicio; considerar
incluir en caso de que no exista SLA con los
proveedores.
• Establecer plantillas para la generación de
documentación técnica (manuales, guías, etc.) sobre los
servicios provistos por IT.
• Definir un repositorio de información para su
centralización, considerando el control de accesos a
esta.
Recomendaciones
Tema Conclusiones
Resolver ▪ Se identifica que la definición de incidente mayor, esta basado
incidentes en la experiencia, conocimiento del negocio y criterio del
mayores personal.
▪ Generalmente, estos son escalados vía telefónica, lo cual no
garantiza que sean documentados en el sistema de tickets.
▪ Existe concordancia, al indicar que el Coordinador de área el
responsable de gestionar, escalar y reportar este tipo de
casos.
Cerrar ▪ Se identifica a nivel herramienta existen ciertos campos
solicitudes e marcados como obligatorios para poder cerrar un ticket, pero
incidentes no existe un estándar de información para compartir con el
usuario sobre la atención/resolución de su ticket.
▪ Se identifica que existen 7 estados de cierre, de los cuales se
coincide en el uso de 4 (Abierto, cerrado, resuelto,
desestimado), interpretando con esto que no existe
trazabilidad durante el ciclo de vida del ticket.
* Alcance de Enevasys
Recomendaciones
• Formalizar la declaración de un incidente mayor, debe
ser realizado por los responsables del servicio, teniendo
en cuenta los criterios de priorización e impacto hacia el
negocio
• Incluir dentro de la práctica de gestión de incidentes, el
tratamiento de incidentes mayores *
• Definir políticas para iniciación de investigación del
incidente mayor (canalización a la práctica de gestión
de problemas) *
• Homologar el flujo de trabajo de las prácticas de
Incidentes y Solicitudes con sus respectivos estados y
transiciones dentro de la herramienta de JSM *
• Generar las plantillas de servicio con campos
obligatorios dentro de JSM *
• Definir y estandarizar hacia toda el área de Tecnología
los parámetros de documentación con vista a negocio.
• Concientizar la importancia de la base de
conocimientos.
Recomendaciones * Alcance de Enevasys

Tema Conclusiones Recomendaciones

Monitorear ▪ Se identifica que el medio empleado para mantener • Definir políticas relacionadas con el registro,
el ciclo de comunicación con el usuario, es la herramienta de categorización, tratamiento y cierre dentro de la práctica de
vida del gestión. Sin embargo, no todas las peticiones son gestión de incidentes y solicitudes *
incidente y registradas y generalmente solo se cambia el estado de • Configurar dentro de JSM las encuestas de satisfacción por
solicitud abierto a cerrado. ticket para ser respondido por la comunidad usuaria *
▪ Las encuestas de satisfacción se realizan de forma anual, • Se sugiere cambiar los periodos de realización de la
quedando bajo responsabilidad de las gerencias su encuesta de satisfacción del servicio por trimestre.
tratamiento. • Compartir los resultados y generar plan de mejora
▪ Actualmente los informes son generados con fines derivado de la encuesta de satisfacción del servicio
estadísticos y de desempeño. involucrando a todos los responsables del servicio

Mejora ▪ Se identifica que no existe actividades relacionadas con • Establecer políticas de revisión y actualización de las
continua la mejora continua. prácticas en un periodo recurrente *
• Generar, analizar y presentar informes de KPIs de las
prácticas para toma de decisiones.
• Efectuar análisis sobre los resultados de las encuestas de
satisfacción.
• Generar planes de mejora derivado de los puntos anteriores
Propuesta de la práctica
Roles y Responsabilidades de la práctica
Dueño
Es la persona responsable que debe
garantizar que la práctica es
adecuada para el propósito. Sus
principales responsabilidades
incluyen el patrocinio, la revisión y
aprobación del diseño, de los
cambios la mejora continua y sus
KPIs.
Gestor
Es la persona responsable de la
gestión operativa de la práctica. Sus
principales responsabilidades
incluyen la capacitación, difusión,
coordinación y aseguramiento de
todas las actividades necesarias para
la ejecución y monitoreo de la
práctica.
Ejecutor
Es el rol que realiza las actividades,
responsabilidades y autoridades que
le han sido asignadas dentro de una
práctica. Opera conforme a la
práctica publicada y vigente.
Proceso de la práctica ( AS IS / TO BE)
Datos fundamentales definidos por El Catador

✓ Catálogo de servicios IT (incidentes y solicitudes de servicio)

✓ Asignación de rol dueño y gestor de la práctica de gestión de incidentes y solicitudes de
servicio

✓ Definición de roles y responsabilidades (Mesa de servicio y grupos resolutores)

✓ Categorías operacionales

✓ Tabla de prioridades y sus criterios

✓ Declaración de un incidente mayor

Factores de éxito
Implantar la cultura de trabajo por procesos y la colaboración entre áreas:

• Trabajar en la resistencia al cambio con las áreas que conforman a Tecnología.

• Diseñar las prácticas desde la ejecución tomando como base a las mejores prácticas
de ITSM.
• La asignación de propiedad y responsabilidad de las prácticas caerá en el personal
clave para asegurar su adopción de éstas hacia todos los niveles (dueños y gestores).
• Generar la difusión de las prácticas con vista a negocio y TI por parte del dueño y/o
gestor
• Establecer mecanismos de revisión sobre el cumplimiento de los KPIs y su nivel de
adopción.
• Los procesos son no secuenciales e iterativos, por lo cual serán necesarias revisiones
periódicas, así como la aplicación de mejoras.
¡ Gracias !