Gestin de Incidentes y Gestin de Problemas ...

Gestin de Incidentes y Gestin de Problemas

Alejandro Teruel Versin 1.0: 28 de octubre 2010 Escrito entre: 4 de octubre al 28 de octubre 2010

Ubicacin de clase
Soporte de servicios (ITIL) Servicio no programado

Son dos procesos ubicado como:

Qu es un incidente?

Para entender el proceso de gestin de incidentes es importante entender bien qu es un incidente. Es un evento cualquiera, un evento inesperado o un evento sintomtico de problemas, actuales o potenciales1? Las interrupciones o desmejoras de servicio, no programadas, son incidentes En el contexto que nos ocupa, no hay duda que una interrupcin no programada a un servicio o una reduccin en la calidad, no programada, con que se presta un servicio constituye un incidente. As, seran ejemplos de incidentes en el contexto de servicios informticos: 1. Que se le niegue el servicio a un usuario autorizado para recibir el servicio; 2. Que a un usuario se le interrumpa, en forma inesperada o sorpresivamente, el servicio que se le estaba prestando; 3. Que a un usuario se le alargue el tiempo de respuesta de un servicio respecto al nivel acordado; 4. Que un usuario no reciba los beneficios acordados;
1 Se trata de un vocablo cuyo significado est siendo alterado o arrastrada por su homfono ingls incident, al menos al juzgar por sus aceptaciones segn la Real Academia de la Lengua : 1. adj. Que sobreviene en el curso de un asunto o negocio y tiene con este algn enlace. U. m. c. s. 2. m. Disputa, ria, pelea entre dos o ms personas. 3. m. Der. Cuestin distinta del principal asunto del juicio, pero con l relacionada, que se ventila y decide por separado, suspendiendo a veces el curso de aquel, y denominndose entonces de previo y especial pronunciamiento. http://buscon.rae.es/draeI/SrvltConsulta?TIPO_BUS=3&LEMA=incidente En contraste, en Ingls, incident significa, segn el diccionario Merriam-Webster: 1: something dependent on or subordinate to something else of greater or principal importance 2 a : an occurrence of an action or situation that is a separate unit of experience : happening b : an accompanying minor occurrence or condition : concomitant 3: an action likely to lead to grave consequences especially in diplomatic matters <a serious border incident> http://www.merriam-webster.com/dictionary/incident

Gestin de Incidentes y Gestin de Problemas ...2 5. Que el prestador del servicio insulte al cliente. Es importante que el prestador de servicio se entere lo ms pronto posible de un incidente de forma de reestablecer el servicio o la calidad del servicio en tiempos acordes con los acuerdos de servicio Adicionalmente el anlisis de la frecuencia, impacto y tipo de incidentes puede arrojar indicios invalorables sobre problemas en uno o ms de los componentes del servicio, as como sugerir oportunidades para mejorar el servicio o para crear nuevos servicios. Algunos eventos programados pueden tambin ser considerados como incidentes? Supongamos que por razones de mantenimiento o actualizacin, se programa la suspensin de un servicio por un perodo de tiempo. Un usuario que desconoca o se olvid de tal programacin, intenta acceder el servicio y reporta o reclama al respecto. Observe que desde el punto de vista de la calidad del servicio prestado, es importante para el prestador saber que se produjo tal reporte o reclamo, pues puede apuntar a fallas en los procedimientos de notificacin y recordatorio de interrupciones programadas, a sealar oportunidades para atender al cliente en perodos de interrupcin, a oportunidades para obtener informacin sobre las expectativas del cliente y a recabar informacin que puede resultar relevante a efectos de ajustar acuerdos de niveles de servicio. De all, que es importante indicar que deben incluirse como incidentes aquellas interrupciones y desmejoras de servicio, no programadas a juicio de alguna de las partes (prestador, cliente, personal de soporte). Note que en algunos casos pueden detectarse y contabilizarse intentos de un cliente a acceder un servicio en su perodo de suspensin programada, a efectos de obtener el tipo de informacin mencionada anteriormente, aunque el cliente no llegue a reportar o reclamar al respecto. Pueden considerarse tambin como incidentes, eventos o situaciones que, a juicio de las partes, pudieran causar una interrupcin o desmejora del servicio? Es decir, hay que esperar que se interrumpa o desmejore el servicio para considerarlo un incidente? De nuevo, un enfoque de calidad total de servicio trata de evitar las interrupciones o desmejoras (es proactivo) y no espera a que ocurran (reactivo). Si un cliente o un miembro del personal de soporte empieza a detectar un olor a quemado en las instalaciones donde se aloja parte del sistema de recursos que atiende el servicio, lo ideal es que lo reporte inmediatamente para que se tomen acciones preventivas. Sera poco responsable que la persona esperara a ver llamaradas, o peor, a que se interrumpiera el servicio. Incluir este tipo de situaciones o eventos en la gestin de incidentes puede incrementar notablemente el tiempo y esfuerzo dedicado a este proceso. Para comenzar se puede incrementar notablemente el esfuerzo invertido en investigar y atender falsos positivos. Supongamos que el olor a quemado fue una ilusin olfativa, o que el dispositivo de dnde emanaban los olores automticamente detect un sobrecalientamiento en sus circuitos, se apag, report tal dato a la sala de control y activ un dispositivo de respaldo en caliente, evitando por completo la interrupcin del servicio: 1. En el caso del dispositivo proactivo, el reporte de la persona es un canal redundante de informacin. Los canales redundantes tienen su utilidad: son invalorables cuando el canal primario falla. Digamos que la redundancia en los reportes es el precio que pagamos por tener un margen de seguridad adicional. Pero, ojo, para que funcione, la informacin que llega por el canal redundante no puede descartarse automticamente. Entre las causas de de varias fallas catastrficas, tal como la falla del reactor nuclear en Three Mile Island en Estados Unidos,

Gestin de Incidentes y Gestin de Problemas ...3 estuvo justamente el descarte de informacin procedentes de canales secundarios por estar sta inconsistente con la procedentedel canal primario (a quin se le cree?). 2. En el caso de la ilusin olfativa, aparentemente se perdi tiempo y esfuerzo para nada. Pero en realidad, la reaccin este tipo de situacin tiene impacto psicolgico. Bien manejada, puede mostrar la seriedad con que el personal de soporte atiende eventos que pudieran llegar a atentar contra la continuidad del servicio y por ende incrementan la confianza y la satisfaccin con el prestador de servicio, y sirve tambin de ejercicio y entrenamiento para el personal de soporte encargado de tal atencin. Mal manejado, puede fcilmente poner de manifiesto la impericia, sobrereaccin, irresponsabilidad o poca seriedad del soporte, puede contribuir al exceso de confianza (bah, vamos aunque seguramente es una falsa alarma...) o el sndrome de all viene el lobo. 3. Peor incluso es el caso del falso positivo malintencionado: el reporte de una aparente avera realizada para distraer esfuerzos para aprovechar descargar un ataque por otro lado... En resumen hemos llegado a que la nocin de un incidente incorpora la interrupcin o desmejora en la calidad del servicio, no programadas a juicio de una de las partes, o que pudiera, a juicio de esas partes, conducir a una interrupcin o desmejora del servicio. Debe el prestador de servicio informarle al cliente de la ocurrencia de un incidente? En muchos modelos de gestin de incidentes se considera que el reporte del incidente fluye del cliente al prestador. Es decir, el cliente reporta y el prestador responde. Sin embargo, a mi juicio, puede haber situaciones en que el flujo es al revs; el prestador detecta el incidente y advierte de su existencia y posibles consecuencias al cliente. Hay una lnea muy delicada aqu: el cliente puede agradecer que le adviertan de una posible falla de servicios (est acercndose una fuerte tormenta elctrica, es recomendable apagar equipos no esenciales), pero tambin pudiera molestarse ante lo que considera un exceso de informacin irrelevante o distractora (viene la tormenta, la tormenta est cerca, la tormenta est an ms cerca, se vio un rayo, acaba de caer un segundo rayo, recordamos que recomendamos apagar equipos, la tormenta est sobre nosotros, la tormenta sigue sobre nosotros). Los pasajeros de aerolneas conocen tambin de la importancia de cerrar el incidente (ya no hay peligro, pueden desabrochar sus cinturones/pueden volver a encender sus equipos). Pienso que las empresas prestadoras de servicio manejan dos culturas respecto a informar a sus clientes de incidentes potencialmente interruptores: 1. La cultura del bajo perfil o caja negra caracterizada por un prestador que prefiere no informar de potenciales interrupciones o desmejoras, hasta que stas ocurran. Todava ms extremo es la cultura del prestador que permanece mudo hasta que lo obligan a hablar, cuyas frases caractersticas incluyen: para qu avisar que se interrumpi el servicio, ya se deben haber enterado, no digas nada, que tienen que saber que estamos tratando de arreglar el problema, mejor no les des una hora estimada de reestablecimiento de servicios para no levantar expectativas...

2. La cultura de la caja transparente, caracterizado por un prestador que informa y ayuda a su cliente a hacerle frente a las interrupciones, permitiendo al cliente interesado obtener informacin sobre el progreso en el tratamiento del incidente.

Gestin de Incidentes y Gestin de Problemas ...4

Debe incluirse como incidente una suspensin programada de servicio, as no sea inesperado para ninguna de las partes? Anteriormente revisamos si el reporte, reclamo o incluso intento de acceso, por parte de un cliente, a un servicio suspendido segn fuera programado pueden considerarse incidentes. Ahora vamos un paso ms all, puede considerar como incidente la suspensin programada de servicio, aunque nadie lo reporte, reclame o trate de acceder el servicio? La suspensin programada de un servicio debe afectar el estado registrado de los componentes pertinentes en la base de configuracin. La bitcora de operaciones debe reflejar tal evento para cualquier auditora o anlisis posterior. La suspensin constituye la razn por la que el servicio no est disponible. Puede tratarse como incidente, si se extiende la nocin de incidente a cualquier evento significativo relacionado con la disponibilidad del servicio. Tal actitud es ms caracterstica de organizaciones proactivas: se advierte al personal de soporte y al personal o agentes de atencin al cliente que el servicio ha sido suspendido, para que la informacin la tengan a la mano por si tienen que atender clientes; la idea es que el agente responda inmediatamente al cliente olvidadizo y no lo ponga en espera mientras revisa la base de configuracin... Definicin de incidente Con base en la discusin anterior, propondr que un incidente es una interrupcin o desmejora, real o estimada, en el disfrute de un servicio. [Falta explicar y pulir esta definicin].

Incidentes y el modelo de servicio

En trminos del modelo de servicio visto en el curso los incidentes pueden tipificarse bsicamente segn las relaciones que contiene el modelo2: Incidente asociado a los beneficios del proceso; Incidente asociado a la coordinacin del proceso; Incidente asociado a los insumos del proceso; Incidente asociado al sistema de recursos ; Incidente asociado al acuerdo del servicio; Incidente asociado a los puntos de contacto; Incidente asociado a las expectativas del cliente; Incidente asociado a oportunidades vista por el prestador; Incidente asociado a algn otro aspecto no cubierto por los puntos anteriores.

Un incidente pudiera estar asociado a ms de una relacin y puede ser conveniente indicar si fue reportado por un prestador, un cliente, un proveedor de insumos u otro.
2 Queda pendiente a futuro revisar las herramientas de apoyo a la gestin de incidentes para revisar si esta taxonoma ya se encuentra representada o si pudiera convenir incorporarla en alguna herramienta.

Gestin de Incidentes y Gestin de Problemas ...5 As por ejemplo: 1. Una interrupcin del servicio o recibir un producto (beneficio) defectuoso, retrasado o errado es un incidente relacionado con los beneficios del proceso, pero tambin podra estar relacionado con los puntos de contacto. 2. No poder encontrar la base de configuracin es un incidente asociado a la coordinacin del proceso, al igual que lo es no saber quin es el responsable de una actividad. 3. Detectar que los insumos estn llegando defectuosos es un incidente evidentemente asociado a los insumos, al igual que recibir una llamada del proveedor indicando que habr una interrupcin en el suministro de los insumos. 4. Oler humo cerca de un recurso es un incidente relacionado con el sistema de recursos. 5. Detectar que el proceso no puede, en un momento dado, cumplir con el acuerdo de nivel de servicio al igual que recibir la solicitud del cliente para modificar el acuerdo de servicio es un incidente asociado al acuerdo de servicio. 6. Enterarse que no lleg todo el personal del proveedor que atiende a los clientes en los puntos de contacto es un incidente asociado los puntos de contacto y el sistema de recursos (humanos). Recibir una queja de un cliente sobre el trato que le fue dispensado es un incidente relacionado con los puntos de contacto y con las expectativas del cliente y podra tambin estar asociado al acuerdo de servicio (lo es claramente si el cliente se refiere al acuerdo). 7. Recibir una consulta o una solicitud del cliente es un incidente asociado a las expectativas del cliente, as sea sobre aspectos no incluidos o cubiertos por el servicio. Adicionalmente podra estar asociada a los puntos de contacto. 8. Recibir una propuesta de mejora, modificacin o eliminacin de servicio es un incidente asociado a oportunidades; si proviene del cliente tambin est asociado a sus expectativas y, posiblemente, a los puntos de contacto. 9. Una solicitud de la prensa pidiendo colaboracin para hacer un artculo sobre el servicio est asociado a aspectos no cubiertos por las otras categoras. El anuncio en prensa de un nuevo impuesto a las empresas prestadoras de servicio tambin podra estar asociada a aspectos no cubiertos por otras categoras, aunque en este caso es casi inevitable pensar que podra afectar las expectativas del cliente (y al ser un cambio con impacto financiero, podra llegar a obligar considerar todo el servicio).

Qu es un problema?

El incidente es como el sntoma, un indicador de que algo anda o podra llegar a andar mal. El problema es, en terminologa ITIL, la causa raz de uno o varios incidentes. Por ejemplo supongamos que se reporta un incidente asociado a los beneficios del servicio: la calidad de los productos que se entregan no cumple con las condiciones establecidas en el acuerdo. La gestin de problemas es el proceso encargado de la labor de resolver, de raz, los problemas subyacentes que causan los incidentes. El problema de la calidad defectuosa de los productos puede deberse a la falla de una mquina, a un error en unas lneas de software, en el entrenamiento inadecuado de un operador que interviene en el proceso del servicio; gestionar problemas significa resolver el problema, por ejemplo reparar o sustituir la mquina, corregir el software, entrenar a esa persona.

Gestin de Incidentes y Gestin de Problemas ...6 Desde el punto de vista lgico, el concepto de causa raz es como la cadena potencialmente infinita de los y por qu? de los nios pequeos: y por qu fall la mquina?, y por qu haba un error en el software?, e y por estaba inadecuadamente entrenado el operador? En una cultura de calidad total, la cadena de los y por qu se sigue investigando varios eslabones ms hacia atrs: cuntos eslabones ms hacia atrs? Analizaremos esta pregunta al analizar cmo debe ser la gestin de incidentes y problemas.

Objetivos claves

El objetivo clave de la Gestin de Incidentes es: Regresar al nivel normal de servicio, tal como est definido en el acuerdo de servicio, en el menor tiempo posible con el menor impacto posible sobre las actividades de negocio de la organizacin y el usuario. Van Bon et al[2005] El objetivo clave de la Gestin de Problemas es: Resolver la raz de los problemas que causan incidentes y por consiguiente evitar que se sigan produciendo incidentes por esa misma causa. Van Bon et al[2005] La gestin de incidentes est muy enfocado a resolverle la situacin al cliente en el corto plazo. No le interesa tanto saber la causa o la raz del problema que se presenta y que produce los incidentes, como encontrar lo ms rpidamente posible, una forma que el cliente pueda continuir con sus actividades, con su negocio, lo ms rpidamente posible (es decir, justamente con el menor impacto posible sobre las actividades de negocio de la organizacin y el usuario). Un paito caliente es aceptable si le resuelve el problema al cliente rpidamente. La gestin de problemas est ms interesada en una solucin definitiva, en evitar que los incidentes se sigan produciendo o multiplicando. Una diferencia clave en la percepcin de calidad que se lleve un cliente depende de la gestin de incidentes. Esto tiene que ver con el hecho que el reporte de un incidente constituye un punto de contacto entre un cliente y el prestador de servicios. Supongamos que un cliente entra a un local de comida rpida y pide un plato determinado y resulta que no hay disponibilidad de tal plato: 1. Una gestin que se limita a informarle al cliente que no hay disponibilidad del plato no va a causarle al cliente una buena impresin. De hecho en este caso no se gestionan los incidentes. 2. Un servicio que le informa al cliente que no hay disponibilidad del plato, se disculpa y toma nota de ello, al menos registra el incidente, pero hay que admitir que como proceso de gestin de un servicio de calidad es bastante rudimentario. 3. Un servicio que hace lo indicado en (2) pero asume que el cliente est interesado en comer rpidamente algo que se parezca al plato pedido (recuerde que se trata de un local de comida rpida), y por ende ofrece tales opciones, en general se llevar una mejor impresin que (1) o (2); siente que ha sido mejor atendido, sobre todo si efectivamente lo que buscaba era comer rpidamente (porque se atendi mejor la expactativa ms importante). La gestin de incidentes es ms completa pues al menos intenta atender expectativas. 4. Un servicio que haga lo indicado en (3) pero adicionalmente le ofrezca al cliente alguna

Gestin de Incidentes y Gestin de Problemas ...7 compensacin por la posible molestia (por ejemplo ofrecerle un plato similar ligeramente ms caro al mismo precio que l que pidi, ofrecerle, sin costo adicional, una racin mayor de alguno de los elementos comunes a ambos platos), probablemente haga que el cliente se fije en el sitio y haga una nota mental para volver a visitarlo en el futuro. En este caso, tiene excelentes probabilidades de que un incidente que originalmente tiene todas la de defraudar las expectativas del cliente, se convierta en una experiencia memorable en la que se superan las expectativas del cliente (Performance Research Associates[2009]). Comparativamente hablando, la gestin de incidentes atiende el corto plazo y la gestin de problemas el mediano plazo. Al proceso de gestin de problemas le interesa que no se repita el mismo incidente en el futuro cercano, con otro cliente. Mencionamos previamente la posible dificultad de determinar la causa-raz, es decir el origen ltimo de los incidentes. En la prctica, hay varias formas de gestionar este tipo de situaciones: 1. Definir la causa-raz como el problema que al resolverse devuelve el nivel de servicio a su nivel acordado. En el caso del local de comida, resolver la situacin que nos impide ofrecer el plato solicitado. Por ejemplo, si faltaba un insumo clave para el plato, al obtener el insumo se volvi al nivel normal de servicio, por lo que la causa-raz era la falta de insumo. 2. La falta del insumo puede considerarse, a su vez, un incidente (o un meta-incidente). Registrar tal falta como un incidente permite llevar estadsticas sobre la frecuencia con que ocurre este tipo de situacin. 3. Considerar la falta de insumo como un problema de raz desconocida. En este enfoque, no esperaramos nuevos incidentes similares, nos abocaramos a estudiar por qu faltaron insumos? Si el proceso de gestin de incidentes registra el incidente y busca la forma rpida en que el cliente pueda seguir disfrutando su servicio, y el proceso de gestin de problemas es resolver la raz de los problemas, quin se encarga de la labor detectivesca de descubrir la cadena que lleva de los incidentes a la raz de los problemas? Esta labor le corresponde al proceso de Gestin de Problemas, cuyas actividades incluyen: 1. Analizar los incidentes para identificar los problemas subyacentes; 2. Registrar el inicio de un problema o caso de bsqueda de falla; 3. Estimar el impacto de los incidentes asociados al caso y la urgencia en resolver el caso; 4. Investigar el caso hasta llegar a un diagnstico que permita o recomendar work-arounds o arreglos temporales o identificar la falla, o todos ellos; 5. Monitorear el contexto de la falla para detectar lo antes posible si hay posibilidades que se extienda o se propague la falla y contener la falla. A esta actividad tambin se le conoce como control de fallas o contencin del problema. 6. Evaluar la falla y proponer y evaluar posibles acciones y soluciones. La evaluacin de las posibles soluciones debe tomar en cuenta los acuerdos de servicio, costos, beneficios, impacto y urgencia. En algunos casos la accin propuesta puede ser hasta vivir con la falla hasta una prxima y programada actualizacin o puede ser proceder urgentemente a sustituir componentes, entre otros. 7. Seleccionar las acciones a tomar, registrar la decisin y proceder a llevarlas a cabo

Gestin de Incidentes y Gestin de Problemas ...8 correctamente. 8. Una vez implantadas las acciones, para cerrar el caso es necesario llevar a cabo una revisin post-implantacin para cerciorarse que la solucin implantada satisfizo sus objetivos. En la prxima seccin presentamos un ejemplo donde esperamos aclarar esta crucial pregunta.

Caso ilustrativo: La falla de un disco

Para aclarar el rol que juega cada uno de los procesos de gestin previstos en ITIL, as como la diferencia entre incidente y problema, analicemos una hipottica lnea en el tiempo disparada por una falla: 1. 11:50:00 a.m. Falla silenciosamente y se apaga uno de los discos del RAID (Redundant Array of Independent Disks, Wiki[2010]), nivel 1 con una copia, que almacena el 20% de las cuentas de correo electrnico. Una falla silenciosa es aquella que no llama la atencin, es decir no dispara alarmas. El nivel 1 de RAID crea una copia de un conjunto de datos en dos o ms discos. Como se trata de un nivel 1 con una sola copia, tenemos para cada disco un respaldo. El disco que fall sale de lnea y slo queda funcionando el disco de respaldo. Es decir, todava no no hay falla en la disponibilidad del servicio de correo. La Gestin de Disponibilidad fue el proceso que insisti en el uso de al menos nivel 1 de RAID. 2. 11:55 a.m. Falla silenciosamente el disco de respaldo3. A partir de este momento debera comenzar a registrarse la falla de disponibilidad para el 20% de los usuarios del correo que tenan sus cuentas en este disco, pero como se trata de una falla silenciosa, quin sabe que acaban de perder la disponibilidad del servicio el 20% de los usuarios del correo? 3. 12:01 p.m. Como estamos en la hora del almuerzo, muchos empleados aprovechan para revisar y usar su correo electrnico. Los primeros usuarios empiezan a darse cuenta que no logran acceder sus cuentas en el sistema de correo electrnico. 4. 12:07 p.m. Los primeros usuarios empiezan a enviar correos electrnicos, a nombre de sus colegas, al administrador del correo electrnico indicando que algunos de sus colegas no tienen acceso a sus cuentas. Los seis minutos que han transcurrido es el tiempo que tardaron algunos de los usuarios en revisar que realmente no tenan acceso (a lo mejor tecle la contrasea mal, qu raro, djame probar otra vez, hmm, puede ser una falla transitorio, le doy unos minutos y vuelvo a intentar), chequear con sus colegas o co-trabajadores y pedirles que notificaran al administrador de correos. 5. 12:10 p.m. Empiezan a entrar llamadas telefnicas al escritorio de ayuda, preguntando qu est pasando, porque los usuarios no logran entrar a sus cuentas o hacer operaciones en las cuentas en que haban logrado entrar. En este caso, hemos supuesto que aunque los correos electrnicos empiezan a llegar antes, stos an no han sido ledos: recuerde que el correo electrnico no garantiza tiempos de entrega, ni la entrega de un correo implica su lectura inmediata. A medida que entran las llamadas, la Gestin de Incidentes empieza a registrar las fallas reportadas de acceso como incidentes. El personal del escritorio de ayuda comienza por pensar, al igual que los usuarios, que los incidentes son debidos bien sea a que los usuarios cometieron fallas al intentar entrar a sus cuentas de correo o que dichos usuarios no o no tienen cuentas o fueron
3 Arturo Puente, un buen amigo y experto en este tipo de lides, me advierte que una doble falla silenciosa de un RAID es sumamente improbable...

Gestin de Incidentes y Gestin de Problemas ...9 revocadas sus permisos de acceso. 6. 12:13 p.m. Uno de los operadores del escritorio de ayuda considera, bien sea por el volumen de incidentes del mismo tipo, bien sea porque tampoco puede entrar a su propia cuenta, bien sea porque no entiende por qu se reporta que el sistema ignora o bota gente que haba estado conectada a su cuenta, alerta a la Gestin de Disponibilidad sobre lo que considera que son ya fallas en la disponibilidad del sistema de correo para algunos usuarios. Tambin alerta a Gestin de Problemas, que en este caso suele ser responsabilidad de la administracin del sistema de correo. De ahora en adelante todos los incidentes de fallas en el uso de las cuentas de correo que se van registrando por Gestin de Incidentes son notificadas automticamente a los que trabajan en la Gestin de Problemas y a los responsables de la Gestin de Disponibilidad. 7. 12:14 p.m. Gestin de Problemas y Gestin de Incidentes ratifican que se indique a los que reporten, y han reportado incidentes, que se est trabajando sobre los incidentes y que si es urgente el envo de correos y no requiere del sistema de la empresa, se enve por sistemas alternos/personales que puedan tener los usuarios (cuentas gmail, yahoo, cantv etc.), o a travs de colegas que todava tienen acceso a sus cuentas. Recuerde que para la Gestin de Incidentes es crucial minimizar el impacto de los incidentes sobre el negocio De all que puede insistir Gestin de Problemas que se activen work-arounds, acciones que permitan parapetear el servicio an antes de que se detecta cul es el problema o causa de los incidentes. Gestin de Disponibilidad avisa a Gestin de Configuracin para que registre el estado actual del sistema de correos (parcialmente operativo). 8. 12:15 p.m. Gestin de Disponibilidad decide empezar a registrar los incidentes como reportes de fallas de disponibilidad. Lo hace retroactivamente, es decir desde el primer incidente registrado de ese tipo (12:10 pm). Gestin de Disponibilidad alerta a Gestin de Continuidad quien es responsable de reestablecer la normalidad de servicios crticos normales en caso de catstrofe. 9. 12:16 p.m. Uno de los administradores del sistema de correo lee los correos que han empezado a llegar y avisa al Escritorio de Ayuda y Gestin de Disponibilidad que los incidentes empezaron a ocurrir al menos a las 12:07 pm. Se agregan estos reportes va correo electrnico a la base de incidentes llevada por Gestin de Incidentes y al registro del problema en la base llevada por Gestin de Problemas. A esta altura slo se puede postular la existencia de una causa comn de los incidentes, cuyos sntomas son los incidentes. Los administradores del sistema de correo (Gestin de Problemas) empiezan a postular hiptesis sobre las posibles causas, con la ayuda de la informacin de la base de la Gestin de Configuracin: 1. 2. 3. 4. 5. 6. Desconexin de un segmento de red, Corrupcin o dao a la base de datos de cuenta-habientes; Configuracin incompatibles de software-cliente del correo electrnico; Corrupcin del cdigo del sistema de correo Falla en los servidores de correo ...

10. 12:18 p.m. Gestin de Continuidad revisa sus planes de contingencia y se da cuenta que slo puede activar dos planes: Plan A: Tumbar el sistema de correo y volverlo a iniciar;

Gestin de Incidentes y Gestin de Problemas ...10 Plan B: Reiniciar el correo a partir del respaldo ms reciente, que resulta ser el del da anterior; Plan C: Activar el sistema de correo electrnico desde las instalaciones de emergencia.

Deciden que dado que no se conoce an la magnitud de la no disponibilidad del sistema (y que no parece estar afectando a todos los usuarios), y que an no se sabe dnde est el problema, es preferible esperar que se avance ms en la Gestin del Problema. 11. 12:21 p.m. Gestin de Problemas descarta (temporalmente) la hiptesis que est daado un segmento de red comn. 12. 12:27 p.m. La ejecucin de diagnsticos sobre el servidor del correo permite a los administradores del sistema de correo (Gestin de Problemas) detectar que estn apagados un disco del RAID del servidor de correo y su (nico) disco espejo. Se avisa a Gestin de Configuracin para que actualice el estado de los dispositivos y los elementos de configuracin que dependan de ellos. Escritorio de ayuda, Gestin de Incidentes, Gestin de Problemas, Gestin de Continuidad son enterados de la situacin. 13. 12:35 p.m. Gestin de Problemas ha determinado que uno de los discos est muerto y no se puede prender y as lo registra. Se actualiza el estado del disco en la base de Gestin de Configuracin, y se propaga la informacin a los interesados. Para ir adelantando, ya que se sabe que se va a requerir cambiar al menos un disco Gestin de Problemas introduce una solicitud urgente de cambio ante la Gestin de Cambios. 14. 12:40 p.m. Gestin de Problemas determina que el segundo disco no est muerto, pero que al prenderlo, trabajo un tiempo corto y se apaga. Los diagnsticos indican que los datos en el disco no parecen intactos y no parecen haberse corrompido. Se agrega la informacin a la informacin que se lleva sobre el problema en la base de Gestin de Problemas. 15. 12:46 p.m. Gestin de Problemas discute varias opciones: El segundo disco est bien pero de alguna manera, el estado del primer disco lo obliga a apagarse. A pesar que prende el segundo disco, tambin est daado.

16. 12:48 p.m. Gestin de Problemas decide poner a prueba la primera opcin. Siguiendo los procedimientos recomendados por Gestin de Cambios, desconectan los dos discos del RAID y deciden, como medida preventiva, y siguiendo los procedimientos de Gestin de Continuidad hacer tres respaldos4 del segundo disco como medida de seguridad. Gracias a las previsiones de Gestin de Disponibilidad hay varios discos de respaldo vacos disponibles. 17. 01:00 p.m. Culmina el respaldo hecho al segundo disco. Gestin de Problemas toman dos de los discos que contienen respaldos, se conectan al RAID y se hacen las pruebas de regresin recomendadas por Gestin de Cambios. 18. 01:10 p.m. Todo parece estar trabajando bien! Gestin de Problemas informa y actualiza Escritorio de Ayuda, Gestin de Configuracin, Gestin de Incidentes, Gestin de Problemas, Gestin de Disponibilidad y Gestin de Cambios. Gestin de Incidentes considera cerrado el incidente y avisa, a travs de Escritorio de Ayuda, a los usuarios afectados que se ha reestablecido completamente el servicio. Para Gestin de Disponibilidad, el servicio vuelve a
4 Por qu tres? Qu hubiera podido pasar si slo se hace un respaldo? Y dos?

Gestin de Incidentes y Gestin de Problemas ...11 estar completamente disponible; con la informacin disponible registra que potencialmente fue afectado el 20% de los usuarios que tenan cuenta en los discos daados. Tambin registra que hubo un impacto indirecto, ms difcil de cuantificar, por cuanto algunos de los afectados consultaron o se apoyaron sobre sus colegas para revisar, reportar y utilizar otras cuentas mientras estuvo recortada la disponibilidad. Tambin toma nota que sirvieron los discos de respaldo que haba recomendado adquirir. Para Gestin de Continuidad culmin la situacin de alerta. 19. 01:20 pm. Como parte de la Gestin del Problema, los administradores del sistema de correo deciden que se harn revisiones cada hora hasta las 6 p.m. del RAID y despus una vez al da por tres das para estar seguro que la falla est resuelta. Tambin deciden que el proceso de Gestin de Problemas debe continuar y registran dos nuevos problemas: Por qu muri el primer disco? Por qu al morir el primer disco, se apagaba el segundo disco?

En resumen, pese a que para Gestin de Incidentes, la situacin de normalidad de funcionamiento del servicio se reestableci (por lo que da por cerrados los incidentes), los administradores no consideran que han llegado al problema raz. Lo ms preocupante es que el dispositivo RAID nivel 1,no funcion cmo se esperaba. Lo preocupante es que deja abierta la posibilidad que cada vez que falla un disco, arrastre a su respaldo a fallar. Avisan a Gestin de Disponibilidad sobre su preocupacin y la apertura de los dos nuevos problemas sobre los que continuarn trabajando.. El anlisis de este caso puede desembocar en otras acciones. Por ejemplo, la Gestin de Disponibilidad puede enfocar la falla silenciosa de los discos del RAID y preguntarse si la incorporacin de algn tipo de alarma no pudiera reducir el tiempo perdido por la falta de disponibilidad. Con base a tal anlisis pudiera proponer mejoras al servicio. En otras circunstancias, por ejemplo si se hubiera detectado la necesidad de cambiar la versin de algn software, se hubiera tenido que proceder de acuerdo a los procesos de Gestin de Versiones. El ejemplo pone de manifiesto algunas fortalezas y debilidades de una metodologa como ITIL. Por un lado, los procesos son extremadamente meticulosos, se intenta mantener comunicados a todos los involucrados e interesados, maximizando la coordinacin, la solucin integral en equipo y minimizando los contratiempos que surgen cuando alguien, en un apuro o urgencia comprensible, se olvida o salta un paso que termina por afectar a otros, en una espiral donde puede fcilmente perderse el control. Por ejemplo, sin el apego a los procedimientos de Gestin de Cambios, el apuro por cambiar los discos puede fcilmente conducir a tumbar, por error, todo el sistema; sin los respaldos, un error de comando puede hacer imposible reiniciar la cuenta de los usuarios donde haba quedado, y as sucesivamente. Por otro lado, la aparente necesidad de manejar coordinadamente tantos procesos resulta sumamente preocupante y es imposible no recordar que ITIL nace en el seno de una de las organizacione burocrticas ms sofisticadas del mundo, como lo es la burocracia gubernamental inglesa. Cabra preguntarse, si ITIL es, en el mundo de la gestin de servicios informticos, la contraparte de las metodologas ceremoniosas del mundo del desarrollo de software y que es cuestin de tiempo que se propongan metodologas ms giles5.
5 Schiesser[2002] asoma varios esquemas posibles de integracin de procesos de gestin: (a) la integracin de gestin de incidentes con gestin de problemas; (b) las dos anteriores con la gestin de continuidad; (c) las tres anteriores con

Gestin de Incidentes y Gestin de Problemas ...12

Mltiples incidentes

En la realidad se producen incidentes que pueden o no estar relacionadas entre si. Por ejemplo, a la vez que empiezan a reportarse los incidentes sobre las cuentas de correos electrnicos mencionados previamente, un cliente reporta que no logra iniciar la impresora de cheques para proveedores. Si no hay suficientes recursos para atender todos los incidentes simultneamente, se suele asignar una prioridad de atencin a los (grupos de) incidentes. Dicha prioridad viene determinada por el impacto estimado del incidente y la urgencia del mismo. El impacto tiene que ver con las prdidas (reales o potenciales) ocasionadas por el incidente6 mientras que la urgencia tiene que ver con el tiempo de respuesta considerado aceptable por el cliente para que se atienda el incidente que lo afecta. Un ejemplo de una matriz de codificacin de prioridades la proporciona van Bon[2005]: Bajo impacto Poca urgencia Urgencia media Muy urgente Planificar atencin Impacto medio Alto impacto Atender en menos de 48 Atender en menos de 24 horas horas

Atender en menos de 48 Atender en menos de 24 Atender en menos de 8 horas horas horas Atender en menos de 24 Atender en menos de 8 horas horas Crtico: atender en menos de una hora

Retos ms significativos
1. Lograr que el cliente se sienta bien atendido al reportar los incidentes. 2. Determinar si un incidente fue un suceso aislado o si es sntoma de una falla que generar ms incidentes, en otras palabras, determinar en qu momento disparar la Gestin de Problemas; 3. Darle la debida urgencia a superar el incidente por sobre resolver el problema subyacente. 4. Diagnosticar rpidamente el problema subyacente. 5. Lograr la colaboracin fluida de todo el personal que trabaja en la cadena que va de la recepcin del reporte de incidente hasta la resolucin del problema raz.

Resulta interesante reorganizar estos retos en la forma de un diagrama Ishikawa o diagrama de causaefecto:

gestin de cambios. 6 Es un error comn confundir el grado de impacto de un problema con la complejidad tcnica que requiere resolverlo. (Quint Wellington Redwood[2005]).

Gestin de Incidentes y Gestin de Problemas ...13

Ntese como el diagrama est sesgado hacia retos que tienen que ver con cmo lograr la urgencia debida para resolver o superar incidentes.

Sntomas de gestin inadecuada de estos procesos

1. No se registran los incidentes; los clientes contactan directamente al personal que creen que les puede resolver las situaciones que detectan; 2. Los incidentes se resuelven en forma aislada, no se identifican agrupamientos debidos a un mismo problema subyacente; 3. Frecuentemente los incidentes escalan en complejidad, impacto y/o urgencia; 4. El tiempo de respuesta ante los incidentes es muy alto; 5. Los clientes se quejan que no los atienden, que los pelotean o los dejan esperando en la lnea cuando tratan de reportar incidentes; 6. Los clientes sienten que los reportes de incidentes son en vano: los problemas persisten indefinidamente; 7. Los clientes se quejan que tienen que reportar lo mismo n veces, a medida que los van transfiriendo de una persona o sistema a otro; 8. Los clientes se quejan que pareciera que el prestador de servicio no entendiera la urgencia de resolver los incidentes que se reportan; 9. Los clientes se quejan que no reciben informacin sobre el progreso de los intentos de subsanar los incidentes, incluso al punto que nadie les avisa cuando el servicio vuelve a la normalidad;

Gestin de Incidentes y Gestin de Problemas ...14 10. Los clientes se persignan cuando reportan incidentes porque es bien sabido entre los clientes que el remedio es peor que la enfermedad; lejos de arreglar el servicio, se empeora al reportarlo. 11. El personal de soporte vive estresado; cada vez que se reportan incidentes que es a cada rato--, saben que empiezan las peleas, las recriminaciones y los gritos de los gerentes. 12. Personal de soporte no tiene claro sus responsabilidad y la interrelacin entre los roles y los procesos de gestin. 13. Es frecuente que se anuncie el reestablecimiento del nivel acordado de servicio y al poco tiempo se presente un incidente igual o similar a los reportados previamente. Si revisamos el diagrama Ishikawa de retos, podemos ver que muchos de estos sntomas inadecuadas de gestin pueden asociarse a retos que no se estaran satisfaciendo. En el siguiente diagrama hemos explicatado estas asociaciones, adicionalmente los escudos numerados corresponden a los indicadores de gestin, segn la numeracin que recibirn en la seccin 11:

Gestin de Incidentes y Gestin de Problemas ...15

10

Por dnde comenzar?

Comenzar por concentrarse en las definiciones ms restringidas de incidente y un nivel bsico de problema-raz y prestar particular atencin al trato que se dispensa al cliente cuando reporta incidentes y a la relacin entre los que atienden a los clientes y el personal ms tcnico que resuelve los problemas subyacentes.

11

Indicadores de gestin
1. Nmero de incidentes en un perodo de tiempo establecido por acuerdo de servicio. 2. Porcentaje de incidentes superados. 3. Horas dedicadas a tratar y resolver incidentes: total, promedio e histogramas. 4. Histograma y tiempo promedio para resolver incidentes. 5. Porcentaje de incidentes resueltos en tiempos indicados por el acuerdo de servicio. 6. Histograma de incidentes por tipo de impacto y urgencia. Porcentaje de incidentes superados por tipo de impacto y urgencia. 7. Nmero e histograma de incidentes que se repiten. 8. Porcentaje de problemas detectados que fueron resueltos. 9. Porcentaje de fallas o problemas con arreglos temporales. 10. Porcentaje de problemas reabiertos. Un problema es reabierto cuando la falla que se diagnostic como causa de incidentes, resulta no serlo. 11. Nivel de satisfaccin de clientes en la atencin y resolucin de incidentes 12. Tendencias en los costos de correccin de fallas.

Basados en Steinberg[2006]:

12

Preguntas abiertas
1. En la seccin 3 se mencion una tipificacin de incidentes segn el modelo propuesto en el curso. Investigar su aplicabilidad a las herramientas existentes de gestin de incidentes. 2. En una clase anterior (Gestin de Configuraciones) se mencion que los subprocesos de gestin son Planificacin, Adquisicin y organizacin de recursos, Direccin, Monitoreo, evaluacin y control, Coordinacin con otros procesos. Identificar tales subprocesos para la Gestin de Incidentes y Problemas. Explorar la idea de distinguir y explicitar las operaciones sobre incidentes y problemas.

13

Referencias

Jan Van Bon, Mike Pieper, Annelies van der Veen (editores): Foundations of IT Service Management, based on ITIL. ITSMF-NL, 2005. Quint Wellington Redwood: Fundamentos de ITIL. Versin 06B, 2005. Randy Steinberg: Measuring ITIL, Trafford Publishing, 2006.

Gestin de Incidentes y Gestin de Problemas ...16

Referencias complementarias Wikipedia: RAID. http://es.wikipedia.org/wiki/RAID#RAID_1_.28Data_Mirroring.29 Consultado 06/10/2010. Performance Research Associates: Wow! Deje al cliente boquiabierto con un servicio fuera de serie. Grupo Nelson, 2009. Rick Schiesser: IT Systems Management: Designing, implementing and managing world-class infrastructures.Prentice-Hall, 2002.