¿En qué consiste la planificación de incidencias?

Flujo para la planificación de incidencias.

Las etapas que se han de seguir para planificar y gestionar correctamente una incidencia se muestran en el proceso descrito a continuación. Este flujo sigue las definiciones de ITIL en su libro Service operations y es utilizado por muchos fabricantes de software a la hora de diseñar los procesos en sus herramientas.

1. Identificación del incidente: todos los elementos del servicio han de ser monitorizados para detectar un incidente tan pronto como ocurre. Idealmente, el incidente debe detectarse antes de afectar a los usuarios del servicio.
2. Registro del incidente: debe ser registrado e identificado con un código único que permita referenciarlo en el futuro. El registro del incidente debe incluir la fecha y hora exacta. Estas fechas serán utilizadas para comprobar el grado de cumplimiento de los diferentes SLAs. Además, se debe incluir toda la información relevante que permita gestionarlo del modo más eficiente posible.
3. Categorización del incidente: asignar una categoría concreta al incidente permite, posteriormente, analizar estadísticas y tendencias en la prestación del servicio. La mayoría de herramientas cuentan con diferentes niveles de granularidad para determinadas categorías.

Un número elevado de categorías aumentará las posibilidades de error en el registro de las incidencias, mientras que un número muy limitado impedirá realizar una priorización adecuada:

1. Priorización de la incidencia: esta etapa es una de las más importantes en la planificación de las incidencias, ya que de ella depende el consumo de los recursos disponibles para recuperar el servicio. La priorización suele asignarse teniendo en cuenta la urgencia de la incidencia y el impacto que ésta está ocasionando. La urgencia viene definida por cuán rápido necesita el negocio que se cierre la incidencia, mientras que el impacto suele venir determinado por el número de usuarios afectados.
2. Diagnóstico inicial: generalmente, la persona, registrando la incidencia, es capaz de realizar un análisis inicial de cuál puede ser la causa del problema en función de la información que le está siendo facilitada. Si es posible, la incidencia se resolverá en este punto.
3. Escalado: en el caso de la que incidencia no haya podido ser resuelta en primera instancia, será necesario escalara la misma. El escalado puede ser funcional, cuando se dirige a un departamento con responsabilidad específica sobre una serie de elementos, o jerárquico cuando la incidencia tiene una relevancia especial y ha de ser comunicado a los gestores del servicio.
4. Investigación y diagnóstico: cuando se ha confirmado que se trata de una incidencia y ésta no ha podido ser resuelta por el primer nivel de soporte, generalmente es necesario realizar análisis para determinar la causa del problema y poder encontrar una solución al mismo. Los análisis se harán en paralelo entre todos los grupos involucrados para tratar de reducir al máximo el tiempo de esta etapa.
5. Resolución: cuando se ha encontrado una posible solución a la incidencia, ésta ha de ser probada. Los participantes, en la resolución de la incidencia, variarán dependiendo de cada caso, pero será normal contar con el usuario afectado, la primera línea de soporte y los grupos especialistas que hayan participado en el diagnóstico.
6. Cierre de la incidencia: la primera línea de soporte se encarga de corroborar que la incidencia está totalmente resuelta. Confirma asimismo que la categoría asignada es la correcta, y además obtiene información sobre la calidad del servicio percibida por el usuario, vía encuestas, y recopila toda la información asociada al incidente para que pueda incorporarse a la base de datos de conocimiento del servicio.

Priorización de incidencias.

Las características que definen a una incidencia a la hora de priorizarla son su urgencia y su impacto. La urgencia puede ser definida como la medida que indica cuán rápidamente ha de ser resuelta una incidencia.

El impacto puede definirse como el daño potencial que puede llegar a causar la incidencia antes de su resolución. Tanto en la definición de la urgencia de una incidencia como de su impacto, los diseñadores del servicio de TI deben trabajar estrechamente con el negocio para establecer una matriz que esté acordada por ambos. Las definiciones de urgencia e impacto dependen del tipo de empresa y del sector al que se dediquen.

Salvando estas peculiaridades de cada negocio, un buen ejemplo de matriz de urgencias podría ser ésta:

1. Urgencia alta:
   1. El daño causado por la incidencia aumenta exponencialmente.
   2. El trabajo que no puede ser realizado normalmente se ve muy afectado por mínimas pérdidas de tiempo.
   3. Puede evitarse que un incidente menor se convierta en un incidente mayor si se actúa rápidamente.
   4. Varios usuarios VIP están afectados por la incidencia.
2. Urgencia media:
   1. El daño causado por la incidencia crece considerablemente con el paso del tiempo.
   2. Un usuario VIP está afectado por la incidencia.
3. Urgencia baja:
   1. El daño causado por la incidencia crece muy lentamente con el paso del tiempo.
   2. El trabajo que no puede ser terminado a causa de la incidencia no se ve fuertemente impactado por pérdidas de tiempo.

La definición del impacto de una incidencia en un servicio de TI podría ser clasificada de la siguiente manera:

1. Impacto alto:
   1. Gran número de usuarios afectado y no pueden realizar su trabajo.
   2. Gran número de clientes afectado y no puede disfrutar de las ventajas del servicio.
   3. El impacto financiero de la incidencia puede superar los 100.000€.
   4. El riesgo reputacional al que se enfrenta la empresa es muy alto.
2. Impacto medio:
   1. Número moderado de usuarios afectado y no pueden realizar su trabajo normalmente.
   2. Número moderado de clientes afectado y no pueden disfrutar de alguna de las ventajas del servicio.
   3. El impacto financiero posiblemente supere los 10.000€, pero será inferior a 100.000€.
   4. El riesgo reputacional al que se enfrenta la empresa es moderado.
3. Impacto bajo:
   1. Número bajo de empleados afectado y no pueden realizar alguna de sus tareas habituales normalmente.
   2. Número mínimo de clientes afectado y no pueden disfrutar completamente de alguna de las ventajas del servicio.
   3. El impacto financiero de la incidencia es mínimo, posiblemente inferior a 10.000€.
   4. El riesgo reputacional de la empresa es mínimo o nulo.

En base a esta categorización de urgencia e impacto, resultaría una matriz, que como se comentaba debe estar realizada conjuntamente con el negocio, servirá para el establecimiento de los SLA de servicio. Así, el tiempo tentativo de resolución de una incidencia dependerá de la clasificación de la misma según la matriz de urgencia e impacto.

Excepcionalmente, se pueden dar incidencias mayores que han se de ser gestionadas por un procedimiento mucho más ágil y con unos SLAs mucho más agresivos. Para poder priorizar correctamente estos incidentes mayores, es recomendable contar con indicadores que ayuden a los gestores del servicio a identificar en qué casos se enfrentan a uno de estos incidentes que requieren una respuesta más rápida. Nuevamente, estos indicadores deben ser acordados previamente con el negocio durante la fase de diseño del servicio.

Ejemplos de indicadores son:

1. Grupos de servicios críticos para el negocio, aplicaciones o infraestructuras donde al producirse una incidencia, por la complejidad de los mismos, no es posible predecir un impacto y el tiempo de resolución es desconocido.
2. Grupos de servicios que soportan funciones vitales de la compañía y el tiempo de restauración de los mismos es excesivamente largo.

Gestión de prioridades con Service Manager.

Se trata de la una herramienta de Microsoft que incluye dentro de su suite Microsoft System Centre. Esta herramienta permite la incorporación de las mejores prácticas en la gestión de los servicios de TI, ayudando a adaptar el departamento de TI a las necesidades reales de la organización. Sus procesos están diseñados siguiendo las recomendaciones de ITIL, incluyendo procesos core para la gestión de incidencias y problemas, el control de cambios y el control y la gestión de las bases de datos de conocimiento.

En primer lugar, se establecen los acuerdos de nivel de servicio para cada valor de prioridad que se haya definido junto con el negocio. El número de valores diferentes para la prioridad dependerá del número de valores que se haya asignado a las categorías impacto y urgencia.

En base a los tiempos de resolución propuestos, la herramienta incluye la posibilidad de definir flujos de trabajo donde se establezcan los puntos en los que es necesario escalar una incidencia para asegurar que se gestionará satisfactoriamente dentro del SLA marcado.

Por cada prioridad, se puede establecer un tiempo tentativo de resolución diferente. Este tiempo está definido en la herramienta como el tiempo de resolución de una incidencia menos el de creación de esta incidencia. Si una incidencia de prioridad 2 es registrada en Service Manager a las 12:00pm, para cumplir el SLA ha de ser cerrada antes de las 14:00pm.

Para facilitar la gestión de los SLAs, la hora máxima a la que la incidencia ha de ser resuelta para no incumplir el nivel de servicio acordado es mostrada en la parte superior de la pantalla junto al número de ticket de la incidencia. Es el campo Resolved by.

En la herramienta, también se configura la regla para asignar la prioridad a una incidencia en base a su urgencia y a su impacto. Por ejemplo, se puede haber definido junto con el negocio la siguiente matriz.

El número de valores para cada categoría es variable, con lo que se podrían definir, por ejemplo, 5 valores diferentes para el impacto. Sin embargo, aumentar el número de valores posibles implica aumentar la complejidad en el soporte del servicio. Es el operador quien, al registrar la incidencia, ha de asignar el valor correspondiente a su impacto y a su urgencia.

Un catálogo demasiado extenso de valores hará que, irremediablemente, en la mayoría de los casos, el operador, con la información disponible en ese momento, no sea capaz de registrar la incidencia con los valores acertados.

No es, por tanto, recomendable utilizar un número muy superior a 5, siendo lo más habitual utilizar los tres valores hasta ahora vistos: alto, medio y bajo. Si suele ser habitual mantener la posibilidad de gestionar incidencias con una prioridad excepcional, los incidentes mayores.

Service Manager es un buen ejemplo de herramienta que permite, de un modo muy sencillo, planificar la resolución de las incidencias que son registradas en el sistema. Se pueden encontrar herramientas mucho más complejas en el mercado para la gestión de incidencias, pero todas ellas cuentan como parte de su core la priorización de las incidencias.