4.2 INCIDENT MANAGEMENT La definicin de ITIL: Una interrupcin no planeada de los o la degradacin en la calidad de los Servicios de TI.

Tambin podemos definir una falla en un elemento de configuracin pero siempre y cuando este no impacte al servicio. Los tipos de incidentes que son reportados por los usuarios a travs de diferentes medios o directamente levantados por el staff tcnico, son: y y y Fallas Preguntas Reporte de requerimientos

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

DEFINICION DE OPERACIN NORMAL DEL SERVICIO: Operacin del Servicio dentro de los lmites del SLA.

ALCANCE (SCOPE), Se define como el lmite 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 tcnico, 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 operacin normal o simplemente informativos. Los REQUERIMIENTOS DE SERVICIO tienen relacin 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 Cada del servicio (Downtime) de la organizacin. Se traduce simplemente en que el servicio est cumpliendo los objetivos por los cuales fue diseado. 2. Permite alinear las actividades de TI con las prioridades de una organizacin, ya este proceso tiene la capacidad de identificar esas prioridades y de manera dinmica 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 organizacin. 4. A travs del proceso de incidentes se puede identificar la necesidad de servicios adicionales o requerimientos de entrenamiento tanto para el personal tcnico 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 Administracin de Servicio. Puede ser usado como indicador para saber qu reas requieren atencin, como justificante para gastos en la implementacin 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 definicin 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 definicin y seguimiento de los calendarios se requiere una herramienta para realizar escalamientos automticos en base a reglas previamente definidas. b. INCIDENT MODEL (incidente Mdelo): 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 estndar de Incidentes Modelos que pueda aplicarse a cualquier incidente que ocurra y que cumpla ese estndar. 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 estndar pueda seguirse bajo un calendario predefinido. Esta definicin permite direccionar incidentes especiales a otros procesos. Por ejemplo incidentes relacionados con la Seguridad pueden ser direccionados a la Administracin de Seguridad de Informacin. Un incidente Modelo debe incluir: y Los pasos que deben seguirse durante el proceso y Un orden cronolgico de dichos pasos, con sus dependencias o co-procesos definidos. y Responsabilidades, quien tiene que hace que cosa. y Calendarios y umbrales para poder ejecutar las acciones y Procedimientos de escalamiento. Quien debe ser contactado y cuando y 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 ejecucin de un incidente a travs de herramientas que permitan automatizar la ejecucin, administracin y escalamiento durante el proceso.

INCIDENTES MAYORES

Los incidentes mayores deben tener un calendario independiente al proceso de los incidentes Estndar, adems 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 sern incidentes y slo estarn creciendo en impacto y en prioridad. El proceso de incidentes mayores se recomienda ser ejecutado por un equipo independiente y el lder de este grupo debe ser el Administrador de Incidentes. Todo esto es con el objetivo de asegurar la provisin de los recursos necesarios y mantener el foco para la ejecucin del proceso y encontrar la solucin tan rpido como lo demande el proceso.

Muchas veces en organizaciones pequeas 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 solucin 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 ejecutndose el proceso de problemas que estara encontrando la causa raz 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 configuracin de una organizacin deben ser monitoreados para detectar posible fallas a tiempo, iniciando as un proceso de administracin de incidentes tan rpido 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 informacin de la naturaleza del mismo es relevante, por lo que debe mantener dentro de un histrico dentro del incidente. Esta accin permite ayudar sobre todo cuando este debe ser escalado a otro grupo de soporte y esta informacin le permite tener a detalle como una pequea capacitacin de todo lo relacionado con el incidente. b. CATEGORIZACION DEL INCIDENTE Algo primordial al registrar un incidente, es poder determinar un cdigo de categorizacin que determina el tipo. Es importante ya que posteriormente nos permite detectar incidentes que ocurren frecuentemente, establecer tendencias que pueden ser utilizadas por la Administracin 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 deberan tener de 3 a 4 niveles en el rbol de categoras. La tcnica para crear este rbol de categoras debe inlcuir lo siguiente: y Tener una sesin de tormenta de ideas involucrando a los grupos del Supervisor del Service Desk y los Administradores de Problemas y En esta sesin se debe decidir el nivel adecuado del rbol de categoras y se debe someter a un pequeo periodo de pruebas. y En este corto periodo se deben de registrar cientos de incidentes que permitan usar las diferentes categoras definidas.

y y

Posteriormente a ese periodo se debe realizar un anlisis de los incidentes registrados partiendo de que a niveles altos de las categoras nos dan tendencias generales de lo que est pasando y nos podemos ir a los siguientes niveles para tener ms el detalle, adicional debemos detectar si hay la necesidad de considerar una categora adicional de nivel superior. El anlisis de los niveles inferiores de las categoras de alto nivel, permite tomar la decisin si las categoras 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 contine siendo relevante. Es importante detectar todo cambio que provoque dificultades en la tendencia de incidentes o en la administracin de reportes, a menos que estos cambios sean realmente requeridos. Si existe actualmente una categorizacin en operacin pero esta no est funcionando adecuadamente, la tcnica descrita anteriormente puede ayudar a solucionar el problema. Finalmente una categorizacin 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 rpido la organizacin necesita la solucin y el nivel de IMPACTO, el impacto que est causando a la organizacin la ocurrencia del incidente, ejemplo el nmero de usuarios que estn siendo afectados, la cada del servicio aunque sea para un nico usuario puede resultar de gran impacto a la organizacin, en conclusin depende de que usuario y cual sea su role en la organizacin. Otros factores que determinan el impacto pueden ser: y Riesgo de vida o del miembro y Nmero de servicios afectados y Nivel de prdidas financieras y Afectacin de la reputacin de la organizacin y Cuando se involucran cuestiones regulatorias o legislativas

UN EJEMPLO DEL CLCULO DE LA PRIORIDAD SE DESCRIBE EN LA SIGUIENTE TABLA: IMPACTO ALTO MEDIO BAJO URGENCIA ALTO MEDIO BAJO 1 2 3 2 3 4 3 4 5 Tiempo de Solucin 1 hrs 8 hrs 24 hrs 48 hrs Planeada

Cdigo de Prioridad 1 2 3 4 5

Descripcin Crtica Alta Media Baja Planeada

Es importante para que el staff tenga claro el nivel de prioridad a seleccionar, que se den guas de ejemplo prcticos 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 guas 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 organizacin 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 peticin fuera de lnea de los niveles de servicio establecidos, generalmente esto ocurre cuando el usuario esta al telfono. Algunas organizaciones considerar los usuarios VIP ( rangos mayores de jerarqua, oficiales, diplomticos, polticos, 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 gua de cmo aplicar los niveles de prioridad para este grupo de personas. Es importante resaltar que los niveles de prioridad son dinmicos 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 situacin. Este dinamismo se puede facilitar a travs del uso de una herramienta que permita calcular la prioridad adecuada en base a la situacin actual durante el ciclo del incidente, y en base a una parametrizacin predefinida.

d. DIAGNOSTICO INCIAL y 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 organizacin 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 solucin 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 sealar que siempre la Mesa de servicio es la duea del incidente, no importa a donde est siendo referido, esta debe ser responsable de la ejecucin del progreso, de mantener informado a los usuarios y del cierre del incidente. y 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 investigacin y diagnstico para la solucin y restauracin 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 solucin, debemos estar consientes de la prioridad real de la organizacin antes de tomar esta decisin.

e. INVESTIGACION Y DIAGNOSTICO Si el usuario final solo est requiriendo informacin, la mesa de servicio debe de proporcionrsela tan pronto como sea posible. Caso diferente cuando lo que se reporta es una falla y se requiere un grado de investigacin y diagnstico para proporcionar la solucin del incidente. Cualquier actividad realizada durante la investigacin y el diagnstico 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 ejecucin de dichas actividades en paralelo. La investigacin puede incluir las siguientes acciones: y Determinar exactamente lo que est mal y lo que el usuario est buscando realmente. y Entender el orden cronolgico en el que han ocurrido los eventos y Determinar el impacto total de incidente, incluyendo el nmero y del tipo de usuarios impactados y 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 relacin a errores de fabricantes y proveedores o en la misma base de conocimientos. f. SOLUCION Y RESTAURACION Cuando una solucin potencial es detectada, esta debe ser aplicada y probada. Las acciones especficas y las personas que deban involucrarse varan dependiendo de la naturaleza de la falla, pero puede involucrar: y Pedirle al usuario que realice algunas acciones directamente en su equipo yo realizarlas remotamente a travs de una herramienta. y La mesa de servicio puede realizar estas acciones de manera centralizada o remotamente a travs de una herramienta de control remoto que le permita diagnosticar e implementar dicha solucin. y Pedir a grupo de especialistas la ejecucin de ciertas acciones para restaurar el servicio. y Pedir a un proveedor tercero o de mantenimiento para resolver la falla. Independiente de donde fue encontrada la solucin se deben de realizar pruebas suficientes para asegurar que la restauracin del servicio es definitiva. En caso de que se requiera la intervencin de varios grupos para encontrar la solucin, quien debe coordinar las actividades involucradas, es el Administrador de Incidentes. Adicional cualquier accin tomada debe ser registrada por quien registro el incidente para mantener el histrico en el registro. Una vez encontrada la solucin, 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: y y CATEGORIA DE CIERRE, Verificar que la categorizacin inicial de incidente es la correcta, de lo contrario realizar la categorizacin de cierre correcta. ENCUESTA DE SATISFACCION DEL SERVICIO, Tener la retroalimentacin del grado de satisfaccin del usuario ya sea correo o una llamada de seguimiento y documentarlo directamente en el incidente como parte del histrico. 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 accin preventiva. Cierre Formal.

Algunas organizaciones utilizan el cierre automtico 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 accin. 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 varan de empresa a empresa pero dichos acuerdos deben de documentarse para servir de gua al grupo de La Mesa de Servicio.

DISPARADORES, ENTRADAS Y SALIDAS, INTERFACES DEL PROCESO DE INCIDENTES Existen varios caminos para disparar un incidente,: y y y Llamadas de usuarios a la mesa de Servicios Automticamente a travs de una Herramienta de Administracin de Eventos Originados por indicaciones de proveedores con motivos de fallas de origen, etc

La Administracin 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 generacin de incidentes, por lo que la administracin de incidentes sirve para divulgar la ocurrencia de un problema en la organizacin ADMINISTRACION DE CONFIGURACIONES, identificar qu equipo es el que est fallando permite determinar el impacto de este, es decir que usuarios se vern afectados en el servicio y determinar el IMPACTO del incidente. Adicional proporciona informacin en base a la categora del elemento de configuracin, de que categora seleccionarse para el incidente y adicional a qu grupo de especialista. La administracin de incidentes mantiene el estado actual de la falla, que permite a la administracin de configuraciones auditar la infraestructura cuando se est trabajando para solucionar el incidente. ADMINISTRACION DE CAMBIOS, Cuando un cambio es requerido para implementar una solucin temporal o una resolucin, se requiere registrar un RFC direccionarse a travs de la administracin de cambios. La administracin 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 administracin de cambios. ADMINISTRACION DE CAPACIDADES, La administracin de incidentes proporciona los indicadores para monitorear el desempeo cuando estos son considerados problema. La administracin de capacidades debe de desarrollar soluciones temporales para los incidentes. ADMINISTRACION DE DISPONIBILIDAD, La administracin 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 administracin de incidentes proporciona los SLM que definen respuestas medibles de la cada del servicio. A travs de reportes permite revisar los SLAs. Permite encontrar debilidades en los servicios y mejorarlas, y tomar acciones a travs 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 administracin de incidentes debe de trabajar:

i. ii. iii. iv. v. vi.

Tiempo de respuesta de incidentes Definicin de impacto Meta de Tiempos de reparacin Definicin de Servicios, que son mapeados a los usuarios Reglas para los requerimientos de servicio Expectativas para retroalimentar a los usuarios

ADMINISTRACION DE INFORMACION La mayora de la informacin utilizada en la administracin de incidentes proviene de las siguientes fuentes: y y Herramientas de administracin de incidentes. Registro de incidentes, etc

La administracin de incidentes requiere acceso a la informacin de Administracin de Configuraciones para identificar que CIs es afectado por el incidente y determinar el impacto del mismo. La base de errores conocidos, proporciona informacin 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 administracin de incidentes. Deben incluir: y y y y y y y y y y y y El total de incidentes creados El detalle de los estados de cada incidente Nmero y porcentaje de incidentes mayores Tiempo requerido para encontrar la solucin, tiempo de cada en base al impacto seleccionado. Porcentaje de incidentes solucionados dentro del tiempo de respuesta acordado. Costo promedio por incidente Nmero de incidentes reabiertos sobre el total de incidentes creados Porcentaje de incidentes cerrados por la mesa de servicio sin haberse escalado a otros niveles. Nmero y porcentaje de incidentes atendidos por cada miembro de la mesa de servicio Nmero y porcentaje de incidentes cerrados remotamente sin necesidad de visita en sitio. Nmero de incidentes ejecutados bajo un incidente modelo. Tiempo de ocurrencia de incidentes durante el da 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 desafos deben de existir para lograr una administracin exitosa de incidentes. y 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. y Convencer al staff tcnico a registrar todo incidente que llega a sus manos. y Disponibilidad de informacin acerca de los problemas y los errores conocidos. Aprender de incidentes pasados como tratar nuevos incidentes. y Integrar la CMS para tener presente la relaciones entre los CIs y tener como punto de referencia el histrico en el primer punto de contacto y 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 y Una buena Mesa de Servicios es clave para tener xito en la administracin de incidentes. y Definicin clara de metas en base a SLAs y Integracin de herramientas de administracin para el control de los procesos y OLAS Y UC capaces de influir en el comportamiento adecuado del staff. C. RIESGOS y 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 informacin 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.