Existe una diferencia entre resolución y cierre de incidentes. Mientras que la primera se asegura de que la situación haya sido atendida, la segunda va un paso más allá al cerciorarse de que todos los interesados estén satisfechos con los resultados finales y el cierre. Por ahora, nos concentraremos en la resolución. En este artículo te decimos cuáles son las mejores prácticas de resolución de incidentes.

Según ITIL, el Service Desk de una empresa puede seguir los siguientes pasos para resolver un incidente:

• Diagnóstico inicial: Un usuario empresarial define el incidente.
  
  
• Escalamiento: Este solicita soporte de un técnico en sitio.
  
  
• Investigación y diagnóstico: Se aplica una solución. Ambos pueden llevarse a cabo durante el diagnóstico inicial y requerir cambios en el software, nuevo hardware o actualizaciones.
  
  
• Resolución y recuperación: Un Service Desk confirma que el servicio del usuario fue restaurado siguiendo el SLA.
  
  
• Cierre: Confirmación por parte del cliente de que el incidente ha sido resuelto.

Entre más información haya disponible, mejor será para todos. Si el Service Desk provee una explicación detallada de cómo un incidente fue resuelto, el equipo de gestión de incidentes puede utilizar estos datos para evaluar los esfuerzos. Con el tiempo, el staff puede aprovechar la información de resolución de incidentes para monitorear la satisfacción del usuario.

También lee: ¿Qué es una matriz de escalamiento en TI?

Una gestión de incidentes efectiva requiere que un Service Desk lleve un registro de las tendencias. De esta manera, es posible recolectar datos para mejorar el servicio y reducir el volumen de incidentes. Pero lo que es más importante, una mesa de servicios puede disponer de las tendencias de datos para acelerar la resolución.

Guía de mejores prácticas de resolución de incidentes

1. Empieza con un buen proceso de gestión de incidentes

Los métodos más populares para resolución de incidentes han sido probados con el tiempo en situaciones de alto estrés. Los siguientes pasos son un punto de partida, pero la idea es construir el proceso a partir de cada incidencia:

• Iniciar con una estrategia simple de “triar y resolver”, una manera de priorizar y abordar los componentes de un incidente al identificar el nivel de severidad de cada uno.
  
  
• Agregar fases adicionales y flujos de trabajo para gestionar incidentes más delicados. Un flujo de trabajo bien definido puede incluir etapas para coordinar, mitigar, resolver y diseccionar para aprender de incidentes pasados.
  
  
• Considerar alternativas basados en estándares como los procesos de gestión de incidentes de ITIL v3, los cuales se usan para priorizar y reducir las fallas del servicio.
  
  
• Siempre tener retroalimentación de fases posteriores a la resolución para agregarla a las etapas iniciales del plan en busca de resoluciones más rápidas en el futuro.

2. Registra la estrategia de resolución

Para solucionar problemas de dispositivos conectados, los bucles OODA (Observar, Orientar, Decidir, Actuar) son un excelente estándar a seguir. Esta herramienta desarrollada por el estratega militar John Boyd explica a individuos y organizaciones cómo ganar en entornos inciertos y caóticos. Los cuatro pasos ya mencionados son la clave. La diferencia más notable con otras estrategias de resolución de problemas es la fase de “orientación”, un acercamiento especialmente útil para dispositivos conectados debido al panorama que tiene de todos los datos operacionales.

3. Establece criterios de respuesta a incidentes con los proveedores

Es de suma importancia establecer criterios concretos y medibles con los proveedores para la clasificación de la prioridad de incidentes y el escalamiento. Es necesario monitorear el proceso de negociación de prioridad con el proveedor para cada incidente, y así actualizar el manual. La prioridad de cada incidente debe ser siempre más alta que la del proveedor, pero es vital medir el nivel de apoyo para establecer expectativas para las partes interesadas.

También lee: ¿Cuándo un incidente se convierte en un problema?

4. Define métricas de incidentes a través de la organización

Las métricas de incidentes estandarizadas permiten medir la eficacia y mejorar la previsibilidad de la respuesta de incidentes. Los KPIs de gestión de incidentes de ITIL v3 son una buena guía para escoger las métricas indicadas. Estas son algunas de las más recomendadas:

• Tiempo Medio para Reparar (MTTR)
• Tiempo de inactividad
• Porcentaje de incidentes reabiertos
• Porcentaje de incidentes resueltos en primer nivel
• Costo de resolución

5. Automatiza el escalamiento

Hay que establecer flujos de trabajo para escalar un incidente a un gerente después de un periodo determinado, incluso cuando los agentes en guardia todavía están siendo alertados.

De igual manera, hay que asegurarse de que los escalamientos se envíen automáticamente a los interesados clave y a los gerentes cuando haya un problema crítico o cuando el SLA sea violado. Con ello, los usuarios empresariales pueden tomar un acercamiento proactivo para lidiar con los incidentes antes de que se salgan de las manos.

También lee: ¿Qué es una matriz de escalamiento en TI?

6. Fomenta colaboraciones en tiempo real

Las plataformas de chat en tiempo real permiten a los colaboradores mantener una comunicación constante. Estas se conectan directamente al sistema de tickets de la gestión de incidentes para asegurar que haya un trabajo en conjunto para su pronta resolución.

Conforme Internet de las Cosas sigue creciendo, los dispositivos conectados son cada vez más vulnerables a incidentes de seguridad, los cuales pueden afectar las ganancias y la reputación de una empresa. Una guía de resolución de incidentes comprensiva permite combatir este y otro tipo de riesgos.

Fuentes: AlertOps, Qopper