Gestión de Incidentes
Introducción y Objetivos
Los objetivos principales de la Gestión de Incidentes son:
- Detectar cualquiera alteración en los servicios TI.
- Registrar y clasificar estas alteraciones.
- Asignar el personal encargado de restaurar el servicio según
se define en el
SLA correspondiente.
Esta actividad requiere un estrecho contacto con los usuarios, por
lo que el Centro de Servicios (Service Desk) debe jugar una papel
esencial en el mismo.
El siguiente diagrama resume el proceso de gestión de incidentes:
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 un incidente es:
“Cualquier evento que no forma parte de la operación
estándar de un servicio y que causa, o puede causar, una
interrupción o una reducción de calidad del mismo”.
Por lo que casi cualquier llamada al Centro de Servicios puede
clasificarse como un incidente, lo que incluye a las Peticiones de
Servicio tales como concesión de nuevas licencias, cambio
de información de acceso, etc. siempre que estos servicios
se consideren estándar.
Cualquier cambio que requiera una modificación de la infraestructura
no se considera un servicio estándar y requiere el inicio
de una Petición de Cambio (RFC)
que debe ser tratada según los principios de la Gestión
de Cambios.
Los principales beneficios de una correcta Gestión de
Incidentes incluyen:
- Mejorar la productividad de los usuarios.
- Cumplimiento de los niveles de servicio acordados en el SLA.
- Mayor control de los procesos y monitorización del servicio.
- Optimización de los recursos disponibles.
- Una CMDB más precisa pues se registran los incidentes
en relación con los elementos de configuración.
- Y principalmente: mejora la satisfacción general de
clientes y usuarios.
Por otro lado una incorrecta Gestión de Incidentes
puede acarrear efectos adversos tales como:
- Reducción de los niveles de servicio.
- Se dilapidan valiosos recursos: demasiada gente o gente del
nivel inadecuado trabajando concurrentemente en la resolución
del incidente.
- Se pierde valiosa información sobre las causas y efectos
de los incidentes para futuras reestructuraciones y evoluciones.
- Se crean clientes y usuarios insatisfechos por la mala y/o
lenta gestión de sus incidentes.
Las principales dificultades a la hora de implementar la Gestión
de Incidentes se resumen en:
- No se siguen los procedimientos previstos y se resuelven
las incidencias sin registrarlas o se escalan innecesariamente
y/o omitiendo los protocolos preestablecidos.
- 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.
- No están bien definidos los niveles de calidad de servicio
ni los productos soportados. Lo que puede provocar que se procesen
peticiones que no se incluían en los servicios previamente
acordados con el cliente.
Me ha surgido la siguiente duda. No comprendo bien si la SLA nos permite categorizar los incidentes entrantes y otorgarle una prioridad. O si también se encarga de definir reglas para el escalamiento en los diferentes niveles de resolución de incidentes.
Marcar mensaje como inapropiado
Por roberto 20/09/2007
Creo que,básicamente los SLA solo proveen, entre otras cosas, los tiempos acordados con el cliente para la prestación de los servicios. La Categorización es otra cosa distinta, es como una forma de ordenar o dividir los incidentes. En los SLA no se provee información acerca de las reglas de escalación, eso es algo interno donde el cliente final no tiene nada que ver.
Marcar mensaje como inapropiado
Por Nore 24/09/2007
En los SLA se pueden definir servicios a cubrir y en que medida, tiempos de respuesta y los limites de atencion que obligan al prestador de servicio, entre otros. Asimismo se pueden incluir conceptos como numero de incidentes cubiertos por tiempo determinado,disponibilidad minima de servicio, pueden ser tan especificos como se desee. En ocasiones tambien consideran sanciones al proveedor en caso de incumplimiento
Marcar mensaje como inapropiado
Por javier 15/11/2007
Hola, si alguien conoce algún software que me ayude a gestionar la base de datos de conocimiento KB, estaría muy agradecido que me lo hiciera saber.
Muchas Gracias.
Marcar mensaje como inapropiado
Por David Jaramillo 19/12/2007
Cada incidente entrante es categorizado en la configuración inicial de la herramienta de soiftware que los gestiona, ahi se debe determinar que calse de usuario es,la prioridad, impacto, urgnacia y el SLA asociado a ese usuario o categoria
Marcar mensaje como inapropiado
Por Johnny 29/04/2009
Si un incidente fue resuelto por una segunda o tercera linea, para una segunda oportunidad el mismo tipo incidente tiene que ser escalado a la linea respectiva o dar la solucion del KB?
Marcar mensaje como inapropiado
Por Hugo Guillen 12/07/2009
SLA: es el perfil o resultados deseados, es una Meta que especifica el Nivel de Servicio que debe brindarse durante la Gestion de Incidentes!
Marcar mensaje como inapropiado
Por GUSTAVO 18/09/2009
Se asume que si se cuenta con una relacional KB se debe registrar y actualizar ese incidente resuelto en la segunda o tercera linea como una mejor practica y publicarla para que en la siguiente oportunidad de ese incidente pueda ser resuelto sin dificultad por el por la primera linea.
Marcar mensaje como inapropiado
Por GUSTAVO ALVARADO 18/09/2009
sobre sla:
Es "niveles de acuerdo de servicio" es un acuerdo entre el proveeder y el implentador del servicio. En otras palabras es un documento formal de compromiso donde el proveedor se compromete a cumplir con ciertos estandares o metricas establecidas. Es importante por lo mismo que las SLA sean medidas o cuantificables para poder ser evaluadas. De acuerdo a esas SLA es posible la terminacion de servicio; por ejemplo al no cumplir con ciertos tiempos o ciertas actividades que se comprimetio.
Ahora sobre la diferencia entre Incidente y requerimiento.
Basicamente no tienen referencia, sobre los incidentes se clasifican:
Incidente: Es basicamente una interrupcion del servicio
Problema: es cuando un incidente se repite mas de una vez.
Evento: degradacion del servicio que no representa una interrupcion.
Sobre el requerimiento creo que te refieres a los RFC que son "peticiones de cambio" son peticiones de cambio de algun tipo por ejemplo una version de software que quiere un cliente, estas deben ser evaluadas y ejecutadas si es el caso.
Espero sea de ayuda
Marcar mensaje como inapropiado
Por Cristian 26/11/2009
Hay dos tipos de incidentes:
Fallas y Requerimientos
Un incidente es una falla cuando un usuario reporta una interrupción en el servicio. Un incidente es un requerimiento cuando un usario solicita información.
Marcar mensaje como inapropiado
Por Sugey 22/01/2010
Ejemplo:
1. Un cambio de password mensual en los servidores ¿es un cambio estándar o pre-aprobado?¿o no es un cambio porque no implica ningún cambio en la infraestructura? si no es un cambio entonces sería una solicitud de servicio???
Marcar mensaje como inapropiado
Por Sugey 28/01/2010
Estoy confundida por qué entonces ¿cuáles son los cambios pre-aprobados?
¿Podrían darme ejemplos de cambios pre-aprobados por favor?
Marcar mensaje como inapropiado
Por Sugey 28/01/2010
En este primer dia del curso online me ha parecido muy completo... en la medida que tenga inquietudes las manifestare.. muchas gracias por esta clase de capacitaciones
Marcar mensaje como inapropiado
Por Martha Isabel 21/05/2010
Teniendo como precedente una empresa en la que se quizo montar una mesa de ayudapero desde un principio no se dfinio claramente las necesidades del cliente...la empresa que brinda el soporte pierde entretanto que el cliente le hace un gol al meterle servicios que no inluiyenron en los ANS
Marcar mensaje como inapropiado
Por Lucia 24/05/2010
Para claus:
Según un poco de experiencia en el área, las tareas programadas no se convierten en incidente por que son internas con el proveedor o de TI, por lo que no genera registro por que son avisadas al usuario con anticipación.
Aunque dentro de los posible TI debe tener un mecanismo de continuidad.
Marcar mensaje como inapropiado
Por Norberth 28/05/2010
Porque si ITIL diferencia incidente de requerimiento en que el primero es por un problema y el segundo es un tema nuevo muchas herramientas de Mesa de Ayuda tratan ambos temas como uno solo. ITIL perminte esta unión?
Marcar mensaje como inapropiado
Por Antonio 07/06/2010
Escribir un nuevo mensaje: [Condiciones]