Situación actual

El área realiza dos procesos principales: gestión de incidencias y gestión de requerimientos, los
cuales siguen el método de trabajo que se muestra:

Entrada: Incidente o requerimiento reportado por el usuario.

Proceso: El área de TI recibe la solicitud o incidente, la registra para su atención; en caso no
pueda solucionarla, lo escala con su jefe directo.
Salida: El usuario brinda conformidad por el servicio brindado.
El área está formada por:

Personal de nivel 1: encargados de registrar y atender los tickets de incidencias o requerimientos

en el sistema.

Soporte de nivel 2: encargados de resolver los incidentes y requerimientos de los servicios de

infraestructura y comunicaciones.

Las vías por las que estos puedan reportar sus inconvenientes de TI o realizar solicitudes son:

Correo electrónico.
Teléfono: a través del Anexo.
Modo presencial: se pueden acercar al área directamente.

4.3 Fase de análisis

El análisis de los resultados se lleva a cabo con la participación del personal del departamento
de SD mediante la realización de reuniones en donde se le presentaron a los analistas y
especialistas los resultados obtenidos de la fase anterior y ellos expresaron sus ideas sobre
cuáles podrían ser las posibles causas de las demoras de tiempo y problemas encontrados en el
proceso de Gestión de Incidentes. Basado en esta sesión se construyó un diagrama causa y
efecto que se muestra en la figura.

A continuación se explican los problemas encontrados en las actividades críticas del proceso
derivadas de la fase anterior, así como las posibles causas que generan estos problemas y las
demoras de tiempo en dichas actividades.

Registro

 Demora de entre dos a cuatro días en el registro de requerimientos recibidos vía correo
electrónico debido al gran volumen de requerimientos que llegan por esta vía.
 No se registran de forma ordenada y consistente las solicitudes recibidas vía telefónica.
 Se encontró que aun cuando los analistas cuentan con los mecanismos para realizar el
registro de requerimientos en línea con el usuario no tienen el compromiso para realizar
esta actividad.
 No se cuenta con un sistema de Distribución Automática de Llamadas (ACD) que permita
llevar un control del número de llamadas entrantes, atendidas y abandonadas, así como
comparar el número de las atendidas con las registradas por los analistas.

Escalado

 Demoras en el cierre de órdenes de servicio por parte de las unidades solucionadoras

de aproximadamente 18 días, esto se debe a que no están definidos los acuerdos de
nivel de servicio (SLA´s) y los acuerdos de nivel de operación (OLA´s) para los servicios
prestados por estas unidades, por lo que éstas no están obligadas a cerrar las órdenes
de servicio en un lapso de tiempo establecido.
  Otra causa de la demora en el cierre de órdenes de servicio es la falta de seguimiento a
los tickets escalado por parte de los analistas y especialistas del SD.

Cierre de tickets

Después de que se cierran todas las órdenes de servicio asociadas a un ticket, existe una demora
de aproximadamente 6 días en el cierre de éste, esto se debe a la falta de seguimiento a los
tickets escalado por parte de los analistas y especialistas del SD.

Los usuarios se sienten desinformados acerca del estado de su solicitud, por lo que gran
porcentaje de las llamadas y correos recibidos por el SD son para hacerle seguimiento a una
solicitud ya hecha.

Inexistencia en el área operativa de un proceso formal a nivel de Gestión de Incidentes.

4.4 Fase de mejoras

Después de identificar las actividades críticas en donde se producen las mayores demoras de
tiempo del proceso y sus posibles causas, se procede a especificar las propuestas de mejora y
cambios en el proceso en general que permitan optimizar el tiempo de solución de incidentes
del SD. Es de resaltar que este es uno de los aportes más importantes de este trabajo para la
empresa, ya que se plantean una serie de modificaciones que de ser implementadas mejoraran
sustancialmente el funcionamiento de la Gestión de Incidencias.

4.4.1 Propuestas de mejoras.

4.4.1.1 Propuesta para disminuir volumen de llamadas y correos electrónicos.

Para disminuir el volumen de llamadas y correos electrónicos se propone identificar las causas
raíces de los incidentes reportados con más frecuencia, para realizar los cambios necesarios en
los sistemas e infraestructura de Tecnología de Información (TI) que permitan prevenir la
ocurrencia de los mismos, así como implementar un sistema de monitorización de hardware y
software que informe al SD mediante alertas los incidentes antes de que sean reportadas por
los usuarios. En este sentido se define una alerta como una situación detectada por los sistemas
de monitoreo, que no forme parte de la operación estándar de servicio y que cause o pueda
causar una interrupción o reducción de la calidad del mismo. De esta forma el SD seguirá un
patrón más proactivo ante los incidentes que van surgiendo.

4.4.1.2 Propuesta para mejorar el registro de requerimientos.

Se propone un nuevo canal para el reporte de incidentes y solicitudes de servicio (autoregistro),

en el cual sean los usuarios los que registren y hagan una clasificación inicial de su solicitud,
generando ellos mismos el número de ticket asociado a la misma, de esta manera los analistas
y especialistas del SD no tienen la necesidad de registrar las solicitudes. Y se podrá llevar un
mejor control de las solicitudes registradas, ya que todos los incidentes reportados por los
usuarios serán registrados en la herramienta SD. Por esta vía el usuario también podría hacer
seguimiento del estado de sus reportes, disminuyendo el volumen de correos electrónico
recibidos por el departamento para este fin, que según el estudio realizado representa un 40%
de los correos recibidos.

4.4.1.3 Propuesta para mejorar el tiempo de cierre de ticket.

Se propone el cierre automático del ticket después de que las unidades solucionadoras cierren
todas las órdenes de servicio asociadas al mismo. Para comprobar con el usuario que el incidente
fue solucionado correctamente se le enviará por correo electrónico si está conforme, si el
usuario no está conforme con la solución se procede a la reapertura del ticket. Se debe crear
una nueva categoría en la clasificación de incidentes llamada “no conformidad” la cual permitirá
medir el porcentaje de incidentes solucionados correctamente.
Con el cierre automático de ticket se elimina la demora de 6 días producida en la actividad de
cierre, mejorando los tiempos de respuestas.

4.4.2 Modelo propuesto del proceso de Gestión de Incidentes.

En esta sección se propone un modelo mejorado del proceso para la Gestión de Incidentes,
con una descripción detallada de los procedimientos a realizar por los analistas y especialistas
en cada una de las actividades del mismo. El modelo propuesto está basado en el proceso de
Gestión de Incidentes que describe ITIL y fue adaptado a las necesidades del SD.

4.4.2.1 Proceso de Gestión de Incidentes del SD.

Asignación

El analista responsable de esta actividad debe leer y analizar cada solicitud, ya sea recibida vía
correo electrónico o vía autoregistro y dependiendo del requerimiento asignarla al primer,
segundo o tercer nivel de soporte.

Registro

Se registra el incidente o solicitud de servicio mediante la apertura de un ticket, para ello se

graba los datos relativos en la Base de Datos de Incidentes. Si se trata de un incidente se
verifica que si ya existe, en cuyo caso se asocia con el incidente existente, en caso contrario se
graba como nuevo incidente. Para después pasar a la actividad de “Clasificación y Soporte
Inicial”

Entradas

Contacto de usuario para informar incidente.

Registro de incidente o solicitud de servicio hechos por el usuario en auto registro.
Entradas desde los servicios de monitorización de hardware y software, que habitualmente se
transforman en incidentes.

Salidas

Base de Datos de Incidentes con la siguiente información:

· Asignación automática de un número de registro (número de ticket)
· Fecha y hora real del momento de la detección.
· Modo de entrada del contacto (correo electrónico, llamada o auto registro).
· Descripción detallada del caso detectado.
· Datos de la persona que realiza el registro.

Clasificación y Soporte Inicial

El SD realiza una clasificación preliminar del incidente para asignarle una prioridad y una
categoría basada en el análisis del registro del incidente creado en la actividad anterior.
La prioridad debe asignarse según los parámetros de impacto y urgencia (definidos en el marco
teórico). La categoría permite identificar inicialmente el tipo de elemento y la razón o síntoma
causante del incidente, facilitando la identificación de la correspondiente acción resolutiva a
realizar.
Adicionalmente en este proceso también se asigna el estado del incidente. Este estado es un
indicador del progreso realizado en la resolución de un incidente abierto y permite definir y
extraer ciertas métricas con el fin de evaluar el Proceso de Gestión de Incidentes.

Entradas

El registro del incidente.

Incidentes que guardan relación con incidentes anteriores.
SLA´s y OLA´s

Salidas

Incidente clasificado.
Detalles del incidente actualizados.
En caso de resolución del incidente se obtendrían los detalles de su resolución.

Resolución del incidente

Normalmente se resuelve el incidente mediante un arreglo temporal, y se llevan a cabo las

acciones oportunas para restaurar el servicio. Las actividades de restauración del servicio se
pueden llevar a cabo por personal de cualquier nivel de soporte. Todas las acciones realizadas
en esta actividad se colocan en el registro de incidentes mediante la creación de bitácoras, ya
sea por la unidad que restauró el servicio o por el SD.

Entradas

Detalle del incidente actualizado.

Cualquier arreglo provisional.

Salidas

Detalles del incidente actualizados.

Incidente resuelto con los detalles relativos a la restauración del servicio.

Comprobación con el Usuario

Se contacta al usuario mediante una encuesta de evaluación de calidad enviada vía correo
electrónico automáticamente después de cerrar el ticket, para comprobar la resolución del
incidente y el restablecimiento normal del servicio.
Entradas

Incidente resuelto.
Restablecimiento del servicio.

Salidas

Conformidad o no del usuario.

Gestión de incidencias

La gestión de incidencias es un proceso existente en el área, el cual se ha descrito antes, es por

ello que para este proceso se han realizado las mejoras correspondientes a las debilidades
encontradas. El objetivo principal de la gestión de incidencias es resolver cualquier incidente
que cause una interrupción en el servicio. Previamente, a describir el rediseño del proceso, se
definen los conceptos que el personal de Service Desk debe tener en cuenta:

Priorización

Escalado
Gestión de requerimientos

La gestión de peticiones se encarga de atender las peticiones de los usuarios proporcionándoles

información o brindando servicios. Se ha realizado el rediseño del proceso siguiendo el flujo
siguiente: