Gestión de Incidencias. Mapa de escalados.

La Gestión de Incidencias siempre tiene una espada de Damocles encima de la cabeza, el tiempo de solución. Siempre y cuando los tiempos sean acordes a los indicadores establecidos en el ANS no habrá ningún problema, la necesidad de mejora llega en el momento en el que este tiempo se demora en exceso. Los retrasos a la hora de solucionar una incidencia suelen motivarse por diferentes razones: dimensionamiento inadecuado, conocimiento insuficiente del entorno,..., y por último mi "favorito" el escalado infinito. Suele ser bastante frecuente encontrarse con incidencias que han pasado de forma reiterada por distintos grupos de soporte, los cuales siempre encuentran una justificación para escalar la incidencia: "he revisado mi parte y está todo bien", "la configuración es la adecuada", "seguro que es un problema del servidor",...

Para evitar este traspaso incontrolado de incidencias de un grupo a otro hay dos factores que se me antojan más que necesarios:

• Realizar un diagnóstico inicial lo más certero posible.
• Disponer de un mapa de escalados.

Ya comenté en su momento la conveniencia de trabajar sobre procedimientos diagnósticos que faciliten al Service Desk la tarea de identificar de forma inequívoca cual es el(los) elemento(s) afectado(s) por una incidencia. Aunque esto solo no será suficiente para encaminar las incidencias al grupo de soporte adecuado, hay que diseñar un Mapa de escalados. Este será la herramienta que se pondrá a disposición del Service Desk para que puedan distribuir de forma correcta las incidencias.

¿Qué hay que tener en cuenta a la hora de crear un mapa de escalados? Tal y como he comentado en otros post todo depende del nivel de madurez con el que cuente la organización. Lo ideal es que el mapa de escalados este embebido en la herramienta de gestión del servicio aunque quizás en la etapa de implantación y durante un corto período de tiempo se puede utilizar una simple hoja de Excel (cuantas menos hojas de Excel se utilicen mucho mejor). Pero en mi opinión hay algo todavía mucho más importante a tener en cuenta y son los criterios a seguir para asignar las incidencias a uno u otro grupo.

¿Cuales son estos criterios? En primer lugar hay que identificar de forma detallada que alcance tiene cada equipo de trabajo dentro de la gestión de incidencias. Este detalle tiene aún más relevancia si tenemos grupos de trabajo con un ámbito común pero con distinto alcance, por ejemplo un grupo N2 Unix y otro N3 Unix. Hay que tener muy claro que tipo de incidencias debe resolver cada grupo.

El otro criterio a tener en cuenta es la categorización o clasificación de las incidencias. En un post previo hablaba sobre la idoneidad de asociar el activo afectado y las preguntas a las que dar respuesta a la hora de clasificar una incidencia: ¿dónde reside el fallo? y ¿que ha provocado el fallo?.

Una vez establecidos los criterios anteriores, la creación del Mapa de escalados será una cuestión de mapeo entre estos y los equipos o grupos de trabajo que tenga la organización. Es importante que esta herramienta de escalados sea puesta en conocimiento de todos los integrantes de la organización. Por último y como todo en este mundo de la gestión de servicios, el Mapa de escalados debe ser una herramienta dinámica, a medida que la organización vaya madurando (sobre todo en lo que a documentación de soluciones tipo se refiere), es muy aconsejable que el alcance en cuanto a la solución de incidencias vaya adecuándose a los niveles menos especializados.

Alberto Álvarez