Cómo crear un proceso de gestión de incidencias
Cómo diseñar un proceso de gestión de incidencias en el que la severidad dimensione todo lo posterior: clasificar antes de diagnosticar, dibujar la reclasificación como una vía y pasar la causa a un registro aparte.
Cómo funciona
Escribe la matriz de prioridad antes que el diagrama
La prioridad es el impacto contra la urgencia, y ambos necesitan niveles declarados: cuántos usuarios, qué nivel de servicio, si hay dinero o seguridad de por medio, con qué rapidez crece el daño, si aguanta una solución temporal. Acuerda eso primero, porque una matriz inventada mientras se dibuja el mapa describe la última incidencia y no la siguiente.
Decide qué cambia de verdad una incidencia grave
Enumera lo que compra la declaración: un responsable con nombre, una sala de crisis, actualizaciones a hora fija, permiso para saltarse la aprobación normal de cambios. Si no cambia nada salvo la etiqueta, la rama es decoración. El ejemplo le dedica dos pasos completos, que es la cantidad honesta de trabajo que hay detrás de ella.
Teclea la recepción y la clasificación como filas
Cada fila de QueryChart es una caja. Pon el disparador en la columna «Box text», después el paso de registro y después el de categorización, y apunta cada fila a la siguiente en la columna «Line to». A las tres filas el mapa ya ha hecho su argumento: la prioridad de la fila 3 se calcula a partir de lo que capturó la fila 2, lo que convierte a la fila 2 en una decisión de diseño y no en un formulario.
Bifurca la decisión de severidad y etiqueta ambas salidas
Cambia a Decision la columna «Shape» de la fila de clasificación, enumera los dos destinos en «Line to» y da después a cada número su respuesta en «Line text». El diagrama se bifurca una sola vez, en «¿Incidencia grave?», aunque la matriz tenga cuatro o cinco niveles, y esas dos etiquetas trabajan más que cualquier otro par de aquí, porque son el único sitio donde cambia la vía.
Apunta la vía de reapertura a un número de fila anterior
Un arreglo que quien reportó rechaza vuelve al diagnóstico: la salida «Reabierta» de la fila 15 apunta a la fila 7. Una severidad mal fijada necesita el mismo tratamiento y el ejemplo no lo dibuja: añade una rama desde las filas de diagnóstico de vuelta a «Clasificar y asignar prioridad». Cada una de ellas es un número menor en la columna «Line to».
Calibra la matriz y nombra después a quien declara
Pon la matriz donde pueda leerla quien registra el ticket y después pruébala: da a dos personas de turnos opuestos las mismas tres descripciones y compara lo que fijan. Que discrepen significa que falta un nivel, no que un compañero sea descuidado. Nombra después a la persona de cada turno que puede responder «Sí» en «¿Incidencia grave?» antes de que el gestor de incidencias esté despierto.
Preguntas frecuentes
¿Cuál es la diferencia entre una incidencia y un problema?
Una incidencia es una interrupción de un servicio; un problema es la causa subyacente de una o varias incidencias. Se mantienen como procesos separados porque corren con relojes distintos: la gestión de incidencias se mide por el tiempo hasta restablecer y la gestión de problemas por si la causa se ha eliminado de verdad, algo que puede llevar semanas. Fundir las dos hace que el trabajo sobre la causa herede la urgencia de la incidencia y se abandone en el momento en que el servicio vuelve.
¿Cómo se decide la prioridad de una incidencia?
A partir del impacto y la urgencia sobre una matriz publicada, no a partir de quién pregunta. El impacto es cuánta organización queda afectada: usuarios, sedes, nivel de servicio, si hay dinero o seguridad de por medio. La urgencia es con qué rapidez crece el daño y si aguanta una solución temporal. La matriz convierte ese par en una prioridad, y solo se gana su sitio si las cifras que hay detrás de la decisión quedan registradas junto a ella: una prioridad que nadie puede reconstruir no se puede discutir cuando resulta estar equivocada.
¿Cuándo debe declararse una incidencia como grave?
Cuando cruza un umbral acordado de antemano: un servicio de primer nivel caído, un número declarado de personas sin poder trabajar, exposición regulatoria o de seguridad, una brecha sospechada. La declaración solo se gana su sitio si cambia comportamientos: un gestor de incidencias con nombre, una sala de crisis, actualizaciones con una cadencia fija. Declarar tarde es el fallo habitual, y el coste de declarar y después desconvocar es muchísimo menor que el coste de una hora de silencio.
¿Una incidencia reabierta debe ser un ticket nuevo?
No: reabre el original, porque los dos registros contestan preguntas distintas. Un ticket nuevo reinicia el reloj de resolución y reporta un arreglo fallido como dos arreglos con éxito, que es precisamente la distorsión que esconde un servicio inestable. Reabrir sobre el mismo registro mantiene el histórico en un solo sitio y hace medible la tasa de reapertura, y la tasa de reapertura es la señal de calidad más honesta que produce un proceso de incidencias.