Priorizando incidencias

0

Cuando se diseña un proceso de gestión de incidencias, especialmente cuando se combina con el despliegue de una herramienta ITSM, uno de los aspectos más importantes es la manera en la que se define la prioridad. Al principio parece una tarea trivial y en muchas ocasiones no pasa de definir una serie de niveles. Pero un análisis más profundo enseguida revela que se trata de un factor clave en el éxito del proceso de gestión de incidencias y que merece una dedicación que normalmente no tiene.

En este post ofreceré una guía para determinar la prioridad en la gestión de incidencias.

¿Qué es la priorización?

Antes de ponernos a describir como calcular la prioridad de las incidencias, es importante definir qué es la prioridad. Priorizar es definir el orden de resolución deseado. Es decir, averiguar qué necesita ser resuelto antes desde el punto de vista del negocio para permitir a nuestros equipos de soporte enfocarse en lo que es necesario en cada momento.
La priorización debe procedimentarse, de forma que cada técnico de soporte sea capaz de determinar la prioridad correcta de forma objetiva. Al final, el técnico obtiene un nivel de prioridad, que utilizará para definir qué debe resolverse primero.

Las recomendaciones de ITIL

ITIL recomienda determinar la prioridad a partir de dos conceptos:

  • Impacto: Medida de los efectos en los procesos de negocio.
  • Urgencia: Medida de cuanto tiempo pasará hasta que el impacto en el negocio sea significante.

Este esquema es muy difícil de aplicar realmente. Por un lado el efecto en los procesos de negocio dependerá del tiempo que esté en la incidencia afectando. Por otro ¿Cómo medimos el tiempo hasta un impacto significativo? Por ejemplo, una caída de la web de ventas nos prova pérdidas de 10.000 € a la hora. Primero, ¿Cuál es el impacto en los procesos de negocio?, pues dependerá de lo que dure la incidencia. Segundo ¿Cuanto tiempo pasa hasta un impacto significativo? ¿Nada? La gran parte de las incidencias impactan desde el minuto 0 y no dejan de impactar mientras duran.

Esto es diferente si tenemos un SLA en juego, ya que podemos pensar en “nuestro negocio” y no en el del cliente y aplicar los conceptos anteriores de forma que:

  • Impacto: Valor de la penalización en caso de rotura.
  • Urgencia: Tiempo hasta la rotura.

Pero claro… la mayoría de SLA’s están basados en la prioridad de la incidencia. Asi qué nos encontramos con el pez que se muerde la cola. ¿Como defino el impacto si depende de la prioridad y la prioridad depende del impacto?

Yo recomiendo, sin salirnos de la definición de ITIL aplicarlo de la siguiente manera:

  • Impacto: La extensión de la incidencia.
  • Urgencia: El efecto temporal en los procesos de negocio. Es decir, cuanto daño hace la incidencia por segundo.

El impacto versa sobre la cantidad de personas (y la importancia de las mismas) afectadas por la incidencia. La urgencia versa sobre el trabajo afectado por la incidencia y como de importante es ese trabajo para el negocio.

Por ejemplo, un retraso de diez minutos en la entrega de los correos tendrá un impacto máximo (todos los usuarios afectados), pero una urgencia muy baja (ya que afecta poco a los procesos de negocio). Otro ejemplo, un PC de un usuario roto tendrá un impacto mínimo, pero el nivel de urgencia puede ser muy diverso, dependiendo del uso que se hacía del PC y como de crítico sea para la organización.

La idea principal es que el técnico determine el impacto y la urgencia, de forma que la prioridad se obtenga de una tabla o matriz a partir de estos valores. De esta manera cada combinación de impacto y urgencia determinará una prioridad diferente.

Determinando significado de la urgencia

Normalmente las organizaciones suelen entender bien el concepto de impacto, pero no suele pasar lo mismo con la urgencia. Es muy habitual ver la urgencia definida como una de las siguientes tres definiciones:

  • Cómo de rápido necesito que se restaure el servicio.
  • Cuál es el grado de bloqueo en su trabajo de la gente afectada.
  • Cuál es la importancia del servicio impactado.

Las tres definiciones están mal. La primera es realmente la definición de la prioridad. Por ejemplo, en el ejemplo anterior del retraso de 10 minutos en la entrega de correos la urgencia será probablemente mínima. Pero dado que está afectando a toda la organización, la prioridad puede tener un valor bajo, intermedio o incluso elevado. El valor final dependerá de la matriz de priorización y el valor que se ha dado para urgencia baja e impacto extenso. Pero muchos técnicos no son capaces de abstraerse del número de personas afectadas a la hora de definir la urgencia. Desde mi punto de vista esto es un error.

La segunda definición se acerca al verdadero significado de la urgencia, pero se olvida de un aspecto clave: el efecto en el negocio. Muchas veces veo definiciones como “Muy alta: El usuario está completamente bloqueado y no puede continuar trabajando”. En esta definición no hay nada sobre lo importante que es el trabajo de esa persona en el negocio. Por ejemplo, para una empresa de servicios de TI, no es lo mismo bloquear los PC’s del call-center (y perder el servicio que da a sus clientes) que los de contabilidad. Unas horas sin el departamento de contabilidad es importante, pero unas horas sin servicio de call-center puede ser catastrófico.

La tercera definición es un error de base. Consiste en tener mapeada la urgencia a los servicios según el nivel de criticidad que tienen en el negocio. Pero olvida que un servicio puede estar afectado de muchas maneras. La importancia de un servicio sólo nos sirve para poner una cota máxima a la urgencia de las incidencias de ese servicio. Por ejemplo, para un negocio de venta on-line su página web es el servicio de TI más importante de todos, por lo que según este criterio todas sus incidencias tendrían urgencia máxima. Ahora imaginemos que un error en una subida cambia el css poniendo en producción los colores del entorno de preproducción (ya que por cierto es buena práctica que visualmente preproducción y producción se diferencien a la vista para evitar errores). Que la web en un momento determinado tenga los colores equivocados no es comparable a una caída de la web, y ambas situaciones afectan a todos los usuarios. Por lo que está claro que la urgencia en ambos casos debe ser diferente, aunque el servicio sea el mismo. Sobre este punto, una anotación: esta es la definición que tienen algunas herramientas, como por ejemplo OTRS, en su sistema, ya que al seleccionar un servicio, te selecciona la urgencia automáticamente. Sinceramente no entiendo como Pink Verify es capaz de certificar herramientas con ese tipo de conceptos equivocados.

Resumiendo, la urgencia es el grado de afectación a los procesos de negocio y como de críticos son estos. ¡Nunca hay que olvidarlo!

¿Cuántos niveles necesito?

Tanto la urgencia, como el impacto o la prioridad deben definirse con un valor. Lo habitual (casi en el 100% de los casos) es establecer unos niveles y dar un significado a cada nivel. Por ejemplo, en una organización la prioridad puede tener tres posible niveles: baja, media o alta.

Como siempre pasa con la prioridad, el determinar cuántos niveles hacen falta es una cuestión que se pasa por alto. Pero bajo mi punto de vista es muy importante. Puede marcar la diferencia entre una prioridad que se ignora y molesta y una que es realmente útil. Lo mismo para el impacto y la urgencia.

Por norma general más niveles permiten más detalle y decisiones más elaboradas. Menos niveles permiten entenderlos más fácilmente por los técnicos y los usuarios. Así, ¿Qué número de niveles es el óptimo?

Normalmente cuatro niveles para el impacto, urgencia y prioridad es lo adecuado, pero en ocasiones es conveniente tener más o menos. Para organizaciones pequeñas, con tres niveles o incluso dos es suficiente. Hay casos que una priorización con dos niveles (normal y alta) es más que suficiente. En organizaciones grandes, con grandes volúmenes de incidencias puede ser necesario tener cinco o incluso seis niveles.

Además es importante mencionar que el número de niveles en la urgencia, el impacto y la prioridad puede ser diferente. Conozco un ejemplo de una organización en la que había seis niveles de impacto, cuatro de urgencia y cinco de prioridad.

Por último, la decisión dependerá de la herramienta de ITSM utilicemos, porque en algunas de ellas es complicado modificar el número de niveles. Por ejemplo, BMC Remedy viene con cuatro niveles de serie y cambiarlo implica desarrollo. En estos casos recomiendo mantenerse con el producto de fábrica ya que probablemente nos traerá más problemas adaptar el código que adaptarnos nosotros.

El nombre de los niveles en el impacto y la urgencia

Hasta hoy no he visto ninguna organización con nombres correctos en la urgencia, impacto y prioridad (por lo menos hasta que realice mi trabajo de consultoría). ¿Por qué los propietarios de los servicios no le prestan la atención adecuada? Ni idea. Pero puedo garantizar que en la mayoría de los casos, escoger los nombres adecuados marca la diferencia entre elecciones de niveles objetivas y subjetivas.

El nombre del nivel debe ser significativo y corresponderse sin dudas con la situación en la que debe usarse. Por ejemplo esta es la definición de impacto que viene de serie en BMC Remedy:

  • 1 – Extenso
  • 2 – Significativo
  • 3 – Moderado
  • 4 – Menor

A primera vista, parece lo más normal para definir un impacto (habla de extensión de la incidencia, que ya es algo). Pero creo que cuando los técnicos empiezan a usarlo, les entran dudas. Por ejemplo, una incidencia deja sin internet a un departamento de una organización. ¿El impacto es significativo o moderado? Pues dependerá del técnico que lo coja. Los nombres son abstractos por lo que a priori los técnicos aplicarán su propio sentido común. Para homogeneizar el criterio será necesaria formación y documentación.

Renombremos los niveles de impacto a:

  • 1 – Compañía
  • 2 – Departamento
  • 3 – Grupo
  • 4 – Individuo

Ahora los técnicos y los usuarios lo tienen mucho más fácil para establecer la correspondencia entre el impacto y los casos reales.

Lo mismo aplica para la urgencia. Hay que evitar usar los conceptos Alta/Baja para la urgencia. Son completamente abstractos. Hay que usar algo como:

  • 1 – Bloqueo crítico
  • 2 – Bloqueo no crítico / Retraso crítico
  • 3 – Retraso no crítico
  • 4 – Molestia

Ahora con estos niveles tenemos claro cuando usar uno u otro. Además está forzando a los técnicos a considerar si el servicio bloqueado es crítico o no, es decir, aplicamos el punto de vista del negocio.

Conjuntamente a mi recomendación de usar nombres con significado, me gustaría añadir:

  • Incluir un número en el nombre, para que el orden esté siempre claro.
  • Usar niveles incrementales. Evitar usar niveles del mismo nivel, sólo para reflejar situaciones diferentes. Por ejemplo, en el caso anterior podría haber separado el bloqueo no crítico del retraso crítico, pero como los consideramos del mismo nivel los juntamos en una.
  • Limitarse al significado del impacto y la urgencia.

Los nombres de los niveles de prioridad

Para la prioridad no podemos usar un nombre significativo. La prioridad es un ente abstracto, resultado de combinar distintos aspectos de la incidencia y no el reflejo de algo en concreto. Por lo tanto no queda más remedio que limitarse a los típicos niveles de Alto/Bajo.

Aún así hay varios aspectos a considerar:

  • Evitar el uso de la palabra urgente. Una incidencia de prioridad “urgente” sólo liará los conceptos de urgencia y prioridad.
  • Definir en el nombre las incidencias críticas (entraremos en ello más adelante)
  • Usar un número y niveles incrementales, como en el caso del impacto y la urgencia.

Incidencias críticas

Las incidencias críticas son un grupo especial de incidencias en donde el negocio está severamente afectado. No llegan al punto de desastres, es decir, algo que puede poner en riesgo la continuidad del negocio, pero sí que son situaciones en las que el negocio sufre bastante.

No hay que confundir las incidencias críticas con:

  • Incidencias masivas: Es una incidencia que afecta a un gran número de usuarios o a todos los usuarios. Una incidencia masiva no tiene por qué ser crítica, y una incidencia crítica puede no ser masiva.
  • Desastres: Un desastre es un nivel por encima de incidencia crítica. Es un tipo de situación en el que la continuidad de la organización peligra. Un incencio por ejemplo es un desastre. De hecho podría decirse que una incidencia crítica está a mitad de camino entre una incidencia normal y un desastre.

Cuando tengo que explicar lo que es una incidencia crítica normalmente uso la siguiente definición: “Es algo que normalmente la alta dirección conoce o se queja si no es avisada de ello”. Cuando el CEO se entera de una incidencia, que no sea en su propio PC, es normalmente porque es crítica.

Cuando sucede una incidencia de alta prioridad, los técnicos pueden dudar sobre si es crítica o no. Y deben definir si lo es, porque normalmente el procedimiento para gestionarla cambia. Para ello yo recomiendo ligar la definición de incidencia crítica a la prioridad. Es decir determinar qué niveles de la prioridad serán críticos. En la mayoría de las organizaciones habrá un nivel de prioridad llamado “crítico” que se corresponderá con la incidencia crítica. Pero en otros puede haber más de uno. En cualquier caso la recomendación es que del nombre de la prioridad se extraiga si es un caso crítico o no. Por ejemplo podríamos tener la siguiente clasificación de prioridad:

  • Muy Alta (Crítica)
  • Alta (Crítica)
  • Media
  • Baja
  • Muy Baja

Así nuestros técnicos y usuarios no tendrán dudas.

La matriz

Una vez están definidos el impacto y la urgencia, el sistema ITSM determinará la prioridad usando una matriz o tabla. Vamos a tratar la definición de esa tabla.

Primero de todo, hay que evitar crear una matriz diagonal. Hay que considerar cada combinación de impacto y urgencia para evaluar que prioridad es la que se corresponde. Para ello hay que comparar las distintas situaciones para evaluar ¿Cuál haría primero? y poner los niveles en concordancia. Para hacer este trabajo es importante involucrar al negocio, ya que el servicio de soporte TI está para el negocio y no para TI. De esta manera veremos como la afectación al negocio está claramente representada en la priorización.

Durante la confección de la matriz se pueden descubrir cosas sobre tu organización. Por ejemplo, descubriremos en qué situaciones considera el negocio que se debe actuar como una incidencia crítica. En otras ocasiones veremos como el negocio no hace distinciones de prioridad ante dos niveles de impacto o urgencia, indicándonos que nos sobran niveles.

En cualquier caso y como resumen, lo más importante es:

  • No limitarse a hacer una matriz diagonal, y evaluar combinación a combinación.
  • Implicar al negocio en la definición.

Uso de la matriz de prioridad

La matriz de prioridad debe ser forzada en todo momento. La mejor manera para conseguirlo es que nuestra herramienta de ITSM lo fuerce. En algunas esto viene de serie, en otras puede configurarse y en otras tendremos que hacer algo de código.

En cualquier caso si dejamos al técnico establecer la prioridad de forma independiente del impacto y la urgencia, la matriz dejará de tener valor, y por consiguiente perderemos la información que nos ha dado el negocio.

Usando la prioridad

Bueno, ya tenemos la prioridad establecida. ¿Y para que nos sirve? Principalmente para tres cosas:

  • Determinar el orden de resolución de incidencias.
  • Definir objetivos de servicio
  • Detectar incidencias críticas

El orden de resolución de incidencias debe basarse sólo en la prioridad. De esta manera nos aseguramos que la prioridad tiene significado y que detectaremos cualquier degradación en este concepto. Es decir, si por culpa de seguir la prioridad se establecen órdenes de resolución que no gustan al negocio, es el momento de revisar la priorización y no la manera de ordenar la resolución.

About author

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y Master in Advanced Studies, pero se ha metido de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert y va en camino de certificarse como PMP. Actualmente trabaja en Idiso, empresa de servicios de distribución hotelera, como responsable de desarrollo y soporte del área de proyectos web e integraciones.

No comments

Te puede interesar...