4.

2 INCIDENT MANAGEMENT

La definición de ITIL: Una interrupción no planeada de los o la degradación en la calidad de los

Servicios de TI. También podemos definir una falla en un elemento de configuración pero siempre
y cuando este no impacte al servicio.

Los tipos de incidentes que son reportados por los usuarios a través de diferentes medios o
directamente levantados por el staff técnico, son:

 Fallas
 Preguntas
 Reporte de requerimientos

PROPOSITO DE INCIDENTES. Restaurar la operación normal del servicio tan pronto como sea
posible, minimizando el riesgo de impacto en la operación de la organización asegurando como
sea posible la calidad en los niveles de servicio y mantener la disponibilidad.

DEFINICION DE OPERACIÓN NORMAL DEL SERVICIO: Operación del Servicio dentro de los límites
del SLA.

ALCANCE (SCOPE), Se define como el límite o grado al que un Procedimiento de Proceso se aplica.

( Un procedimiento es un documento que contiene los pasos a seguir para ejecutar determinada
actividad, y un proceso contiene un conjunto estructurado de secuencia de actividades para
cumplir un objetivo)

ALCANCE DE INCIDENTES:

No todos los eventos que llegan a una mesa de ayuda son incidentes ya sea reportados por los
usuarios o levantados directamente por el staff técnico, para que este evento se clasifique como
incidente este debe estar interrumpiendo el servicio. Aquellos eventos que no interrumpen los
acuerdos de servicio son llamados Requerimientos de Servicio y son indicadores de la operación
normal o simplemente informativos. Los REQUERIMIENTOS DE SERVICIO tienen relación con el
proceso de REQUEST FULFILMENT.

(CUMPLIMIENTO DEL PETICION, Proceso responsable de administrar el Ciclo de Vida de todas las
Peticiones de Servicio).
VALOR DE LOS INCIDENTES

1. El detectar y resolver incidentes da como resultado reducir la Caída del servicio

(Downtime) de la organización. Se traduce simplemente en que el servicio está
cumpliendo los objetivos por los cuales fue diseñado.
2. Permite alinear las actividades de TI con las prioridades de una organización, ya este
proceso tiene la capacidad de identificar esas prioridades y de manera dinámica
proporcionar los recursos necesarios para atender esas prioridades.
3. Habilidad de identificar mejoras potenciales en el servicio, gracias a que se tiene bien
definido el alcance de un incidente y de estar en contacto directo con las actividades del
personal operativo de la organización.
4. A través del proceso de incidentes se puede identificar la necesidad de servicios
adicionales o requerimientos de entrenamiento tanto para el personal técnico como
operativo.

Estas son una de las razones por las que el Proceso de incidentes es uno de los primeros
procesos a ser implementados en proyectos de Administración de Servicio. Puede ser usado
como indicador para saber qué áreas requieren atención, como justificante para gastos en la
implementación de otros procesos.

CONCEPTOS BASICOS

a. Timescales (Calendarios): Estos deben acordarse para todas las etapas del proceso de
incidentes y dependen del nivel de prioridad del mismo. Se basan en la definición en los
acuerdos de servicio SLAs, OLAs y UCs. Adicional todos los grupos de soporte deben estar
enterados de los detalles de los mismos. Para automatizar la definición y seguimiento de
los calendarios se requiere una herramienta para realizar escalamientos automáticos en
base a reglas previamente definidas.
b. INCIDENT MODEL (incidente Módelo): Algunos incidentes no son siempre nuevos, pueden
ser eventos que han pasado y que vuelven a presentarse nuevamente. Es por eso que
resulta necesario definir un estándar de Incidentes Modelos que pueda aplicarse a
cualquier incidente que ocurra y que cumpla ese estándar. Un incidente Modelo tiene
definido claramente los pasos deben de seguirse durante el proceso. Una herramienta de
soporte permite administrar este proceso y asegurar que ese estándar pueda seguirse
bajo un calendario predefinido. Esta definición permite direccionar incidentes especiales a
otros procesos. Por ejemplo incidentes relacionados con la Seguridad pueden ser
direccionados a la Administración de Seguridad de Información.
Un incidente Modelo debe incluir:
 Los pasos que deben seguirse durante el proceso
 Un orden cronológico de dichos pasos, con sus dependencias o co-procesos
definidos.
 Responsabilidades, quien tiene que hace que cosa.
 Calendarios y umbrales para poder ejecutar las acciones
 Procedimientos de escalamiento. Quien debe ser contactado y cuando
 Preservar cualquier evidencia de cualquier actividad relacionada, en especial
aquellas que se involucren con la seguridad y capacidad.

Los incidentes modelos deben ser entradas para la ejecución de un incidente a través de
herramientas que permitan automatizar la ejecución, administración y escalamiento
durante el proceso.

INCIDENTES MAYORES

Los incidentes mayores deben tener un calendario independiente al proceso de los

incidentes Estándar, además es tiempo debe ser mucho menor y se debe considerar una
urgencia alta. Muchas veces se pueden confundir con Problemas, por eso es importante
indicar que cuando se habla de incidentes aunque sean mayores siempre serán incidentes
y sólo estarán creciendo en impacto y en prioridad.

El proceso de incidentes mayores se recomienda ser ejecutado por un equipo

independiente y el líder de este grupo debe ser el Administrador de Incidentes. Todo esto
es con el objetivo de asegurar la provisión de los recursos necesarios y mantener el foco
para la ejecución del proceso y encontrar la solución tan rápido como lo demande el
proceso.

Muchas veces en organizaciones pequeñas el encargado de la mesa de ayuda puede tener

el role de Administrador de Incidentes mayores, mientras que en organizaciones grandes
debe existir un Administrador de Incidentes mayores como tal para coordinar los procesos
de incidentes mayores quien debe estar reportando directamente al Administrador de
Incidentes.
 Cuando la solución debe ser investigada al mismo tiempo, se hace necesario involucrar al
Administrador de Problemas, aun que el Administrador de Incidentes está obligado a
restaurar el servicio lo antes posible y separadamente debe estar ejecutándose el proceso
de problemas que estaría encontrando la causa raíz del problemas. La mesa de ayuda está
obligada a mantener a los usuarios informados acerca de los avances del mismo. Adicional
debe de registrar todas las actividades.

ACTIVIDADES DEL PROCESO, METODOS Y TECNICAS

Usualmente no es ideal para las organizaciones que se comience el trabajo de un proceso de

incidentes hasta que el incidente ocurra, en la medida que sea posible los principales elementos
de configuración de una organización deben ser monitoreados para detectar posible fallas a
tiempo, iniciando así un proceso de administración de incidentes tan rápido como sea posible
antes de que impacte a los usuarios.

a. REGISTRO DE INCIDENTES (INCIDENT LOGGING)

El registro de incidentes debe hacerse completamente indicando la hora y la fecha del
mismo independientemente de su origen.
Toda la información de la naturaleza del mismo es relevante, por lo que debe mantener
dentro de un histórico dentro del incidente. Esta acción permite ayudar sobre todo
cuando este debe ser escalado a otro grupo de soporte y esta información le permite
tener a detalle como una pequeña capacitación de todo lo relacionado con el incidente.
b. CATEGORIZACION DEL INCIDENTE
Algo primordial al registrar un incidente, es poder determinar un código de categorización
que determina el tipo. Es importante ya que posteriormente nos permite detectar
incidentes que ocurren frecuentemente, establecer tendencias que pueden ser utilizadas
por la Administración de Problemas, de Provisiones o de cualquier otro proceso de ITSM.
Recordemos que un proceso de Requerimiento de Servicio no es un incidente por lo cual
no debe cometerse el error de registrarse como tal.
Utilizar herramientas facilitan este proceso, generalmente deberían tener de 3 a 4 niveles
en el árbol de categorías. La técnica para crear este árbol de categorías debe inlcuir lo
siguiente:
 Tener una sesión de tormenta de ideas involucrando a los grupos del Supervisor
del Service Desk y los Administradores de Problemas
 En esta sesión se debe decidir el nivel adecuado del árbol de categorías y se debe
someter a un pequeño periodo de pruebas.
 En este corto periodo se deben de registrar cientos de incidentes que permitan
usar las diferentes categorías definidas.
  Posteriormente a ese periodo se debe realizar un análisis de los incidentes
registrados partiendo de que a niveles altos de las categorías nos dan tendencias
generales de lo que está pasando y nos podemos ir a los siguientes niveles para
tener más el detalle, adicional debemos detectar si hay la necesidad de considerar
una categoría adicional de nivel superior.
 El análisis de los niveles inferiores de las categorías de alto nivel, permite tomar la
decisión si las categorías inferiores son necesarias.
 Repetir esta actividad en un segundo periodo de tiempo a corto plazo por ejemplo
en 3 meses, para asegurar todo aquello que continúe siendo relevante. Es
importante detectar todo cambio que provoque dificultades en la tendencia de
incidentes o en la administración de reportes, a menos que estos cambios sean
realmente requeridos.

Si existe actualmente una categorización en operación pero esta no está

funcionando adecuadamente, la técnica descrita anteriormente puede ayudar a
solucionar el problema.

Finalmente una categorización sirve como verificador de lo que realmente está

ocurriendo con el incidente, sobre todo cuando no se ha llenado correctamente
los detalles del mismo. Es una buena referencia de lo que está pasando.

c. PRIORIDAD DEL INCIDENTES

Igualmente importante durante el registro es establecer una prioridad del Incidente,
indicando como debe de ser ejecutado tanto por la herramienta de soporte como el staff
de soporte. Es determinado por la URGENCIA, que tan rápido la organización necesita la
solución y el nivel de IMPACTO, el impacto que está causando a la organización la
ocurrencia del incidente, ejemplo el número de usuarios que están siendo afectados, la
caída del servicio aunque sea para un único usuario puede resultar de gran impacto a la
organización, en conclusión depende de que usuario y cual sea su role en la organización.
Otros factores que determinan el impacto pueden ser:
 Riesgo de vida o del miembro
 Número de servicios afectados
 Nivel de pérdidas financieras
 Afectación de la reputación de la organización
 Cuando se involucran cuestiones regulatorias o legislativas
 UN EJEMPLO DEL CÁLCULO DE LA PRIORIDAD SE DESCRIBE EN LA SIGUIENTE
TABLA:

IMPACTO
ALTO MEDIO BAJO

URGENCIA
ALTO 1 2 3
MEDIO 2 3 4
BAJO 3 4 5

Código de Prioridad Descripción Tiempo de Solución

1 Crítica 1 hrs
2 Alta 8 hrs
3 Media 24 hrs
4 Baja 48 hrs
5 Planeada Planeada

Es importante para que el staff tenga claro el nivel de prioridad a seleccionar, que se den
guías de ejemplo prácticos para que se pueda seleccionar la adecuada prioridad del caso.
El seleccionar la urgencia y el impacto adecuado que determinen la adecuada prioridad
deben estar en esas guías que deben haber generado durante los acuerdos de nivel de
servicio.
No hay que olvidar que en ocasiones estos niveles de prioridad normal deben hacerse a un
lado sobre todo cuando la organización así lo requiera o cuando un usuario es
demandante que obliga a romper los niveles de servicio establecidos, simplemente se
resuelve en la Mesa de ayuda como una petición fuera de línea de los niveles de servicio
establecidos, generalmente esto ocurre cuando el usuario esta al teléfono.
Algunas organizaciones considerar los usuarios VIP ( rangos mayores de jerarquía,
oficiales, diplomáticos, políticos, directores, gerentes, etc) En donde los incidentes deben
ejecutarse con una alta prioridad y donde el staff de la mesa de ayuda debe tener una
guía de cómo aplicar los niveles de prioridad para este grupo de personas.
Es importante resaltar que los niveles de prioridad son dinámicos dependiendo de si
circunstancias cambian, si un incidente no es resuelto dentro de los acuerdos de niveles de
servicio, de que la prioridad cambie en base a nueva situación. Este dinamismo se puede
facilitar a través del uso de una herramienta que permita calcular la prioridad adecuada en
base a la situación actual durante el ciclo del incidente, y en base a una parametrización
predefinida.
d. DIAGNOSTICO INCIAL
 ECALAMIENTO FUNCIONAL, Tan pronto como quede claro para la Mesa de Servicio
que no podrá resolver el incidente por si sola y que el tiempo de los acuerdos de
niveles de servicio haya caducado, el incidente debe ser escalado.
En este sentido dentro de la organización se recomienda contar con un segundo nivel
de soporte que solucione el incidente, y siguiendo el esquema contar con un tercer
nivel de soporte en caso de que la solución no se proporcione en el segundo nivel.
Algunas veces ese tercer nivel de soporte puede involucrar terceros como
proveedores de Software, Hardware, Fabricantes o proveedores de servicio. Las reglas
de escalamiento deben estar acordadas bajo los acuerdos de servicios
correspondientes ya sea internamente con los OLAs o externamente con los UCs.
Importante señalar que siempre la Mesa de servicio es la dueña del incidente, no
importa a donde esté siendo referido, esta debe ser responsable de la ejecución del
progreso, de mantener informado a los usuarios y del cierre del incidente.
 ESCALAMIENTO POR JERARQUICO, Si un incidente tiene un prioridad considerada los
encargados del TI por lo menos deben estar enterados. Adicional este tipo de
escalamiento puede ocurrir cuando se está invirtiendo demasiado tiempo en la
invirtiendo demasiado tiempo en la investigación y diagnóstico para la solución y
restauración del servicio y existen complicaciones. Importante notificar a los altos
mandos para el caso de que se requiera recursos adicionales, involucrar proveedores o
servicios de terceros. Igual se utiliza cuando no existe un avance de la persona que
tiene asignado el incidente. Todos los detalles del escalamiento deben ser registrada
en el incidente por la Mesa de Servicio. En caso de que exista otro incidente con la
misma prioridad, entre la Mesa de Servicios y el Administrador de Incidentes deben de
decidir cual incidente se deberá escalar para comenzar su solución, debemos estar
consientes de la prioridad real de la organización antes de tomar esta decisión.
e. INVESTIGACION Y DIAGNOSTICO

Si el usuario final solo está requiriendo información, la mesa de servicio debe de

proporcionársela tan pronto como sea posible. Caso diferente cuando lo que se reporta es
una falla y se requiere un grado de investigación y diagnóstico para proporcionar la
solución del incidente. Cualquier actividad realizada durante la investigación y el
diagnóstico debe ser documentada a detalle. Los tiempo se que pueden involucrar
durante estas actividades puede exceder los acuerdos de nivel de servicio establecidos por
lo que se debe contar con una herramienta que le permita a la mesa de servicio no sobre
pasar dichos acuerdos permitiendo la ejecución de dichas actividades en paralelo.
La investigación puede incluir las siguientes acciones:
 Determinar exactamente lo que está mal y lo que el usuario está buscando realmente.
 Entender el orden cronológico en el que han ocurrido los eventos
 Determinar el impacto total de incidente, incluyendo el número y del tipo de usuarios
impactados
 Identificar la causa que puedo ocasionar dicho incidente buscando en registros
incidentes pasados, registro de problemas o errores conocidos en la base de datos,
algo registrado en relación a errores de fabricantes y proveedores o en la misma base
de conocimientos.

f. SOLUCION Y RESTAURACION

Cuando una solución potencial es detectada, esta debe ser aplicada y probada. Las
acciones específicas y las personas que deban involucrarse varían dependiendo de la
naturaleza de la falla, pero puede involucrar:
 Pedirle al usuario que realice algunas acciones directamente en su equipo yo
realizarlas remotamente a través de una herramienta.
 La mesa de servicio puede realizar estas acciones de manera centralizada o
remotamente a través de una herramienta de control remoto que le permita
diagnosticar e implementar dicha solución.
 Pedir a grupo de especialistas la ejecución de ciertas acciones para restaurar el
servicio.
 Pedir a un proveedor tercero o de mantenimiento para resolver la falla.

Independiente de donde fue encontrada la solución se deben de realizar pruebas

suficientes para asegurar que la restauración del servicio es definitiva.

En caso de que se requiera la intervención de varios grupos para encontrar la solución,

quien debe coordinar las actividades involucradas, es el Administrador de Incidentes.
 Adicional cualquier acción tomada debe ser registrada por quien registro el incidente para
mantener el histórico en el registro. Una vez encontrada la solución, el caso debe se
asignado a la Mesa de Servicio para su cierre.

g. CIERRE DE INCIDENTE
La Mesa de Servicio debe verificar que el incidente ha sido resuelto completamente y que
el usuario está satisfecho y de acuerdo con que el incidente sea cerrado. Para eso la mesa
de servicio debe verificar lo siguiente:

 CATEGORIA DE CIERRE, Verificar que la categorización inicial de incidente es la

correcta, de lo contrario realizar la categorización de cierre correcta.
 ENCUESTA DE SATISFACCION DEL SERVICIO, Tener la retroalimentación del grado
de satisfacción del usuario ya sea correo o una llamada de seguimiento y
documentarlo directamente en el incidente como parte del histórico.
 APARICION O RECURRENCIA DEL PROBLEMA? Determinar con un conjunto con el
grupo de soluciones si el problema puede aparecer nuevamente y decidir las
acciones preventivas necesarias para evitar dicha ocurrencia. En conjunto con el
Administrador de problemas, levantar un registro de problema relacionando todo
esos casos para iniciar una acción preventiva.
 Cierre Formal.

Algunas organizaciones utilizan el cierre automático durante el periodo especificado.

Cuando es de esta manera, es importante que así se haga previo acuerdo con los usuarios
finales y todo mundo esté de acuerdo con esta acción. No siempre resulta adecuado
cuando se trata de incidentes mayores y cuando se involucra VIPs.

h. REGLAS PARA REABRIR UN INCIDENTE, Se establecen acuerdos para definir cuando un

incidente puede ser reabierto, fuera de esas reglas se debe de crear un nuevo incidente.
Dichas reglas varían de empresa a empresa pero dichos acuerdos deben de documentarse
para servir de guía al grupo de La Mesa de Servicio.
DISPARADORES, ENTRADAS Y SALIDAS, INTERFACES DEL PROCESO DE INCIDENTES

Existen varios caminos para disparar un incidente,:

 Llamadas de usuarios a la mesa de Servicios

 Automáticamente a través de una Herramienta de Administración de Eventos
 Originados por indicaciones de proveedores con motivos de fallas de origen, etc

La Administración de Incidentes tiene interfaz con los siguientes procesos:

 ADMINISTRACION DE PROBLEMAS, Los incidentes generalmente se originan de un

problema subyacente, este debe ser solucionado para que no provoque la generación de
incidentes, por lo que la administración de incidentes sirve para divulgar la ocurrencia de
un problema en la organización
 ADMINISTRACION DE CONFIGURACIONES, identificar qué equipo es el que está fallando
permite determinar el impacto de este, es decir que usuarios se verán afectados en el
servicio y determinar el IMPACTO del incidente. Adicional proporciona información en
base a la categoría del elemento de configuración, de que categoría seleccionarse para el
incidente y adicional a qué grupo de especialista. La administración de incidentes
mantiene el estado actual de la falla, que permite a la administración de configuraciones
auditar la infraestructura cuando se está trabajando para solucionar el incidente.
 ADMINISTRACION DE CAMBIOS, Cuando un cambio es requerido para implementar una
solución temporal o una resolución, se requiere registrar un RFC direccionarse a través de
la administración de cambios. La administración de incidentes puede detectar si la
ocurrencia de incidentes puede provenir de haberse implementado un cambio y resolver
en la medida la ocurrencia de dichos incidentes, como un plan de backup considerado en
la administración de cambios.
 ADMINISTRACION DE CAPACIDADES, La administración de incidentes proporciona los
indicadores para monitorear el desempeño cuando estos son considerados problema. La
administración de capacidades debe de desarrollar soluciones temporales para los
incidentes.
 ADMINISTRACION DE DISPONIBILIDAD, La administración de incidentes es utilizada para
determinar la disponibilidad de los servicios de TI y detectar cuando el ciclo de vida de los
incidentes debe mejorarse.
 SLM, La administración de incidentes proporciona los SLM que definen respuestas
medibles de la caída del servicio. A través de reportes permite revisar los SLAs. Permite
encontrar debilidades en los servicios y mejorarlas, y tomar acciones a través del SLM
como parte de la mejora continua en el servicio (SIP Service Improvement program).
 El SLM define los acuerdos de niveles de servicio aceptables sobre los cuales La
administración de incidentes debe de trabajar:

i. Tiempo de respuesta de incidentes

ii. Definición de impacto
iii. Meta de Tiempos de reparación
iv. Definición de Servicios, que son mapeados a los usuarios
v. Reglas para los requerimientos de servicio
vi. Expectativas para retroalimentar a los usuarios

ADMINISTRACION DE INFORMACION

La mayoría de la información utilizada en la administración de incidentes proviene de las

siguientes fuentes:

 Herramientas de administración de incidentes.

 Registro de incidentes, etc

La administración de incidentes requiere acceso a la información de Administración de

Configuraciones para identificar que CIs es afectado por el incidente y determinar el impacto del
mismo.

La base de errores conocidos, proporciona información de soluciones posibles y temporales.

METRICAS

Son usadas para monitorear y reportar y en todo caso juzgar la efectividad y eficiencia del proceso
de la administración de incidentes. Deben incluir:

 El total de incidentes creados

 El detalle de los estados de cada incidente
 Número y porcentaje de incidentes mayores
 Tiempo requerido para encontrar la solución, tiempo de caída en base al impacto
seleccionado.
 Porcentaje de incidentes solucionados dentro del tiempo de respuesta acordado.
 Costo promedio por incidente
 Número de incidentes reabiertos sobre el total de incidentes creados
 Porcentaje de incidentes cerrados por la mesa de servicio sin haberse escalado a otros
niveles.
 Número y porcentaje de incidentes atendidos por cada miembro de la mesa de servicio
 Número y porcentaje de incidentes cerrados remotamente sin necesidad de visita en sitio.
 Número de incidentes ejecutados bajo un incidente modelo.
  Tiempo de ocurrencia de incidentes durante el día para detectar los las horas picos y
asegurar los que se tienen los recursos necesarios para atenderlos.

Los reportes deben ser generados con la autoridad de de incidentes quien deberá determinar la
lista de las personas a las cuales se deistribuiran: Los administradores de servicio de TI, los grupos
de especialistas de soporte, igual considera tener disponible algunos para los usuarios como los de
SLA.

DESAFIOS, FACTORES DE ÉXITO CRITICOS Y RIESGOS

A. DEAFIOS
Los siguientes desafíos deben de existir para lograr una administración exitosa de
incidentes.
 Posibilidad de detectar la ocurrencia de incidentes tempranamente. Educar a los
usuarios finales a reportar las fallas, utilizar los super usuarios, herramientas de
reporte de incidentes.
 Convencer al staff técnico a registrar todo incidente que llega a sus manos.
 Disponibilidad de información acerca de los problemas y los errores conocidos.
Aprender de incidentes pasados como tratar nuevos incidentes.
 Integrar la CMS para tener presente la relaciones entre los CIs y tener como punto
de referencia el histórico en el primer punto de contacto
 Integrar el proceso de SLM parta determinar el impacto y la prioridad del
incidente y realizar el proceso de escalamiento adecuado.
B. FACTORES DE ÉXITO CRITICOS
 Una buena Mesa de Servicios es clave para tener éxito en la administración de
incidentes.
 Definición clara de metas en base a SLAs
 Integración de herramientas de administración para el control de los procesos
 OLAS Y UC capaces de influir en el comportamiento adecuado del staff.
C. RIESGOS
 El registro de incidentes que no puedan atenderse base el tiempo de respuesta
adecuado por no contar con los recursos o entrenamiento adecuado, por no
contar con instrumentos que nos permitan levantar alarmas del cumplimiento de
los acuerdos de nivel de servicio o que nos indiquen el continuar con el progreso
del mismo, contar con herramientas que no nos pueden proporcionar la
información adecuada en el momento adecuado por malas integraciones, errores
en los objetivos o acciones por no estar alineados o la inexistencia de OLAS o UCs.