Estado de incidencia

0

Cuando un gestor se encuentra con el reto de implantar un proceso de gestión de incidencias es habitual tener que definir los estados bajo los que se representará una incidencia. Es posible que la plataforma ITSM escogida ya contenga un flujo determinado, pero hoy en día es cada vez más común utilizar herramientas que no han sido diseñadas específicamente para la gestión de incidencias, con lo que se tendrá que diseñar a medida un flujo de trabajo. La base de este flujo de trabajo será el campo de estado. ¿Cuál es el conjunto de estados ideal? Pues aquí os dejo mi experiencia y mi consejo. Cómo ya hice con otros procesos como problemas o riesgos, lo haré desde un punto de vista práctico.

Seguir ITIL

Si hay un proceso que ha sido implantado más que los otros en ITIL, este es la gestión de incidencias. Es el proceso con un retorno más rápido, y suele ser escogido como un quick-win. Por lo tanto es el proceso que más feedback a tenido y que más ha demostrado su utilidad.

Yo personalmente creo que hoy en día las buenas prácticas recomendadas por ITIL en gestión de incidencias siguen siendo válidas. Incluso en los vaivenes que vivimos con las metodologías ágiles, este proceso ha ido sobreviviendo y son pocas las empresas que se han atrevido a “agilizarlo”.

Por lo tanto mis recomendaciones se van a basar en gran medida en este proceso. Pero no va a ser un “copia y pega”. No, todo lo contrario.

Recomendación 1: Desanclar los estados de los equipos

El estado es una representación de la situación del equipo, por lo que no debe representar al equipo que hay detrás. En mi carrera he visto empresas con estados como “Nivel 2” o “En Desarrollo” son estados ligados al equipo que está resolviendo el caso. Podemos (y debemos) tener el equipo asignado en otro campo. Pero no debemos reflejar en el estado, el equipo que lo atiende.

Recomendación 2: Utilizar un subcampo de estado y limitar la lista de estados

Hay muchísimas situaciones en las que puede estar una incidencia:

  • Esperando a ser atendida
  • Investigándose
  • Investigándose, pero sin encontrar la respuesta
  • Esperando a que se reproduzca de nuevo (aunque esto debería ser más propio de problemas)
  • Esperando a que se resuelva otro ticket
  • Resuelta con una solución.
  • “Arreglada sola” (Os doy mi palabra que he visto este estado 🙂 )
  • Etc.

Si queremos tener una granularidad tan elevada, podemos tenerla, pero fuera del campo de estado. Podemos tener un subcampo de estado. Lo he visto como “Categoría de estado”, “Subestado” o “Motivo de estado”. Los estados deben ser pocos o si no liarán mucho a los usuarios.

Recomendación 3: Alinear estados con los SLA

El campo de estado debe dejar claro cuando se miden tiempos en un SLA. En un SLA de incidencias, al crear objetivos de servicio se suelen hacer mediciones sobre el tiempo que se tarda en resolver o atender un caso. Los campos de clasificación (servicio, prioridad, equipo) determinarán qué objetivo se está midiendo. Pero el campo que debe determinar si se está midiendo o no, es el campo de estado. Esto hará que sea muy fácil de entender por los equipos cuando un SLA contabiliza o no.

Recomendación 4: Ignorar el estado “en progreso”

No aporta valor. A priori parece que este estado indica que la incidencia ha comenzado a tratarse y que eso otorga transparencia al equipo. Pero mi experiencia me dice que:

  • Muchos incidentes tienen poco tiempo entre “en progreso” y “resuelto”, por lo que se usa durante poco rato (o ninguno).
  • Si les permites a los agentes, saltarse este estado se lo saltarán en más del 90% de los casos.
  • Si hay SLA’s relacionados con este estado, los agentes comenzarán a usarlo mal. Cuando mides a las personas, éstas cambian su comportamiento.
  • Si has creado SLA’s relacionados con este estado, probablemente no lo haces teniendo en cuenta a negocio sino con el afán de controlar.

Recomendación 5: No representar las fases de resolución de la incidencia

Las fases de la incidencia, tal y como las define ITIL son una buena guía de los pasos que deben dar los agentes para resolverlas. Son las fases de registro, clasificación, investigación, resolución. Si queremos tener control de la fase en la que estamos, podemos tenerlo en otro campo, como hace BMC Remedy. Pero recomiendo no hacerlo porque no veo que aporte valor, y añade molestos “clicks” a los agentes.

Así deberemos evitar estados como “Investigando”, “Pendiente de clasificar” o similares.

Recomendación 6: Reflejar la confirmación del usuario

Una muy buena práctica que nos introduce ITIL es la confirmación de la resolución. Es decir, asegurar que el usuario nos confirme que el servicio ha quedado restablecido. En muchas organizaciones, cuando un ticket se resuelve, se manda un mail a usuario afectado y acto seguido se cierra la incidencia. Esto es una mala práctica por los siguientes motivos:

  • Que el técnico considere que está resuelta no es una comprobación suficiente. El usuario es el único que lo puede comprobar.
  • El usuario suele interpretar como mala calidad el decirle al servicio que se ha equivocado, que no estaba resuelta. Si esto se repite en una incidencia puede incluso llevar al enfado.
  • La petición de confirmación suele interpretarse como buen servicio, y aumenta la satisfacción del usuario.
  • Evita reaperturas de incidencias, lo cual simplifica el cálculo de SLA y evita conflictos.

Hay muchas formas para confirmar una incidencia: una llamada, un correo solicitando la confirmación, confirmación por silencio al cabo de X días. Pero en cualquier caso, una confirmación que indique que el usuario ha confirmado y ha tenido la oportunidad de negar la resolución.

El esquema propuesto

Tras las recomendaciones anteriores, me atrevo a presentaros el siguiente conjunto de estados:

  • Abierto: Es el estado de una incidencia que está asignada a un equipo y que está pendiente de resolverse. Aglutina cualquier situación en la que el equipo debe trabajar para resolver esta incidencia. Así, por ejemplo, las siguientes situaciones se corresponden al estado abierto:
    • Asignada, pero en cola para resolverse.
    • Parada para hacerse más adelante.
    • Investigándose pero sin poder reproducirla
    • Resolviéndose.
  • Bloqueada: También llamada “Pendiente” o “En Pausa”. Hace referencia a que el equipo que la tiene asignada no puede resolverla, por el momento, por una causa que excede su responsabilidad. Son ejemplos de bloqueo: “Estar pendiente de una aprobación”, “esperar a que el usuario final nos proporcione una información”, “Esperar a una subida a producción”, etc. Pero no ses un ejemplo de bloqueo, “en cola para ser tratada”. Este estado suele excluirse de la medición de tiempos de SLA. Un caso especial de bloqueadas podrían ser las duplicadas con clientes diferentes, o lo que viene siendo una incidencia con múltiples afectados o incidencias masivas, típicas en incidencias críticas.
  • Resuelta: En este estado el agente considera que la incidencia está resuelta, pero no está confirmado este hecho por el cliente o usuario afectado. Normalmente este estado suele excluirse de la medición de tiempos de SLA.
  • Cerrada: La incidencia ya no debe procesarse más. Esto puede ser porque está resuelta y confirmada por el usuario final; o porque se ha confirmado con el usuario que no existía realmente la incidencia o porque se ha decidido no resolverla. Si se desean separar estos casos, recomiendo el uso de subestados o motivos. En este estado está lista para ser archivada, procesada por la gestión de problemas o por cualquier otro proceso que sea posterior a la gestión de incidencias.
  • Cancelada: Una incidencia cancelada es equivalente a borrada. Es una incidencia que no debería haber estado registrada en un comienzo. Esto puede ser porque se registro una incidencia de un usuario que no tenía el servicio. O que la incidencia realmente era una petición. O que la incidencia estaba duplicada (con el mismo usuario). En cualquier caso es buena práctica no borrar incidencias, y cancelarlas. Las canceladas suelen excluirse de cualquier informe.

Lo menos importante de estos estados es el nombre. Probablemente estéis más a gusto con otros nombres. Lo importante es su significado, y os recomiendo ceñiros a los que os digo.

Conclusiones

En este artículo os he presentado los estados que siempre he recomendado cuando he actuado de consultor. Y han tenido buena aceptación. De hecho no estoy inventando nada. Son prácticamente los mismos que se pueden encontrar en muchos ITSM de serie. Quizás, la única diferencia es el estado “En progreso”, que yo prefiero obviar.

El problema principal en esta fase de diseño es que toda la organización puede entender lo que es una incidencia, y toda la organización puede opinar (y opinará) sobre qué estados son los más adecuados. Es uno de esos casos en los que hasta el camarero que nos sirve el café puede erigirse como experto y opinar.

He implantado este sistema en varias organizaciones con miles (o decenas de miles en un caso) de usuarios y cientos de agentes, con éxito y sin modificación tras los ciclos de mejora continua. Así que estoy bastante convencido de su idoneidad. Por lo que os recomiendo saltaros varios ciclos PDCA e implantar directamente algo que está contrastado que funciona.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información.
Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector.
Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo.
Actualmente trabaja en Sunhotels, como responsable del equipo de operaciones TI.

Sin comentarios