Source: https://eualblog.wordpress.com/2014/11/20/gestion-de-incidencias/
Timestamp: 2018-06-18 13:03:46+00:00

Document:
Gestión de Incidencias | Blog de Eugenio Guzman
Publicado el 20 noviembre, 2014 21 noviembre, 2014 por eual
Por otro lado, también es importante diferenciar la Gestión de Incidencias de la Gestión de Peticiones, que se ocupa de las diversas solicitudes que los usuarios plantean para mejorar el servicio, no cuando éste falla.
Detectar cualquier alteración en los servicios TI.
Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios debe jugar un papel esencial en el mismo.
El siguiente diagrama resume el proceso de Gestión de Incidencias:
Proceso de la Gestión de Incidencias
Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software, según el libro de Soporte del Servicio de ITIL® una incidencia es:
Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, a excepción las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc.
Los principales beneficios de una correcta Gestión de Incidencias incluyen:
Una CMDB más precisa, pues se registran los incidentes en relación con los elementos de configuración.
Por otro lado una incorrecta Gestión de Incidencias puede acarrear efectos adversos tales como:
Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución de la incidencia.
Se pierde valiosa información sobre las causas y efectos de las incidencias para futuras reestructuraciones y evoluciones.
Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidencias.
Las principales dificultades a la hora de implementar la Gestión de Incidencias se resumen en:
No existe un margen operativo que permita gestionar los “picos” de incidencias, por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
Es frecuente que existan múltiples incidencias concurrentes, por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas.
La priorización se basa esencialmente en dos parámetros:
Impacto: determina la importancia de la incidencia dependiendo de cómo ésta afecta a los procesos de negocio y/o del número de usuarios afectados.
Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución de la incidencia y/o el nivel de servicio acordado en el SLA.
Dependiendo de la prioridad, se asignarán los recursos necesarios para la resolución de la incidencia.
Básicamente hay dos tipos de escalado:
Escalado funcional: Se requiere el apoyo de un especialista de más alto nivel para resolver la incidencia.
Escalado jerárquico: Debemos acudir a un responsable de mayor autoridad para tomar decisiones que se escapan de las atribuciones asignadas a ese nivel, como, por ejemplo, asignar más recursos para la resolución de un incidente específico.
El escalado puede incluir más niveles en grandes organizaciones, o por el contrario, en el caso de PYMES, integrar diferentes niveles.
El siguiente diagrama muestra los procesos implicados en la correcta Gestión de Incidencias:
La admisión y registro de la incidencia es el primer y necesario paso para una correcta gestión del mismo.
El proceso de registro debe realizarse inmediatamente, pues resulta mucho más costoso hacerlo posteriormente y se corre el riesgo de que la aparición de nuevas incidencias demore indefinidamente el proceso.
Comprobación de que ese incidente aún no ha sido registrado: es muy habitual que más de un usuario notifique la misma incidencia y por lo tanto han de evitarse duplicaciones innecesarias.
Asignación de referencia: al incidente se le asignará una referencia que le identificará unívocamente, tanto en los procesos internos como en las comunicaciones con el cliente.
Registro inicial: se ha de introducir en la base de datos asociada la información básica necesaria para el procesamiento del incidente (hora, descripción del incidente, sistemas afectados…).
Información de apoyo: se incluirá cualquier información relevante para la resolución del incidente que puede ser solicitada al cliente a través de un formulario específico, o que puede ser obtenida de la propia CMDB (hardware interrelacionado), etc.
Notificación del incidente: en los casos en que el incidente pueda afectar a otros usuarios, éstos deben ser notificados para que conozcan cómo esta incidencia puede afectar su flujo habitual de trabajo.
La clasificación de un incidente tiene como objetivo principal el recopilar toda la información que pueda ser utilizada para la resolución del mismo.
Asignación de recursos: si el Centro de Servicios no puede resolver el incidente en primera instancia, designará al personal de soporte técnico responsable de su resolución (segundo nivel).
En primera instancia, se examina el incidente con ayuda de la KB para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.
Si la resolución del incidente se escapa de las posibilidades del Centro de Servicios éste redirecciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente, se seguirán los protocolos de escalado predeterminados.
Si fuera necesario, paralelamente a la resolución de la incidencia se puede emitir una Petición de Cambio (RFC) que se enviaría a la Gestión de Peticiones. Por otro lado, si la incidencia fuera recurrente y no se encontrase una solución definitiva, se deberá informar a la Gestión de Problemas para el estudio detallado de las causas subyacentes.
Incorpora el proceso de resolución al SKMS.
Actualiza la información en la CMDB sobre los elementos de configuración (CIs) implicados en el incidente.
La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidencias.
Por otro lado una correcta Gestión de Incidencias requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:
Un SKMS que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Un SKMS actualizado permite:
Convertir el know how de los técnicos en un activo duradero de la empresa.
Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una extranet, lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
Una CMDB que permita conocer todas las configuraciones actuales y el impacto que éstas puedan tener en la resolución del incidente.
Para el correcto seguimiento de todo el proceso, es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:
Etiquetas: Centro de Servicios, Gestión de Incidencias, ITIL V3, Proceso de Incidencias, TICategorías: Gestión, TI

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución