Estrategias para reducir la acumulación de Incidentes

Este artículo ha sido sugerido por alguien que conozco hace mucho tiempo que es ingeniera especializada en Gestión de Servicios TI (la llamaré Linda). Ha asumido recientemente un nuevo rol como Gestor de Provisión de Servicio en una empresa nueva (es decir, que tiene que ocuparse de un nuevo papel y una nueva organización). La primera cosa que notó el primer día era que, aunque su empresa (la llamaré Widgetco) tiene sólo 600 usuarios y 8 de personal informático, había más de 600 Incidentes activos, algunos de ellos abiertos hacía 6 meses.

WidgetCo no utiliza ITIL ni tiene ningún conocimiento de Gestión de Servicios TI, aunque sin duda ésto cambiará. La pregunta que me hizo mi amiga era: “Qué tipo de medidas puedo tomar para reducir el número de Incidentes atrasados a un nivel más razonable?”

Aquí tiene algunas de las cosas que haría yo, sin un orden especial.

1. Avise a los altos cargos, a los directores y a los patrocinadores del proyecto de lo que ha descubierto. Deles un resumen rápido del problema, señale lo que va a hacer y cuánto tiempo tardará, y prometa presentarles un informe al final de este plazo. Si crea informes de
gestión que muestra el rendimiento frente a un Acuerdo de Nivel de Servicio (SLA), avíseles que éstos y posiblemente otras estadísticas podrían verse afectados mientras pone al día el trabajo.

2. Considere avisar a los clientes o usuarios de lo que está haciendo, especialmente si afectará negativamente a corto plazo la calidad del servicio.

3. Dé a su personal unas pautas sobre la calidad (Linda me comentó que no se registra cada Incidente). Éstas deben incluir:

Registre cada Incidente
Si resuelve un Incidente, póngalo como resuelto en el sistema dentro de tres horas
Establezca unas reglas de calidad básicas, tales como proveer descripciones de Incidente y de resolución adecuadas.

4. Averigüe si algunos de los Incidentes atrasados son en realidad Solicitudes de Cambio. Hay que distinguir entre Incidentes (en los que ha ocurrido un fallo en un servicio del usuario) y situaciones en que los clientes solicitan cambio en los servicios (aunque éstos sean importantes).

5. Examine uno por uno los Incidentes más antiguos (por ejemplo de abril a julio). Puede necesitar que alguien le ayude con ésto. La mayoría de las herramientas ITSM como Serio permiten que se adjunten ‘valores de estado’ personalizados a los Incidentes (en Serio, Agent Status A & B (Estado de Agente A y B) son ejemplos de ésto). Crée unos valores de estado para adjuntar a sus Incidentes que aclaren lo que significan. Ésto también puede ayudarle a recordar cuáles han sido examinados.

Por ejemplo,

“Pendiente” (ya lo ha examinado y requiere todavía actuación)
“Cambio registrado” (este Incidente es realmente un Cambio)
“No requiere acción” (según mi experiencia, puede encontrar algunos Incidentes que o bien ya están resueltos pero todavía no se ha actualizado el sistema, o bien las circunstancias han cambiado y ya no se necesita continuar).
“En espera” (el estado no estará claro hasta otra revisión. Naturalmente, es deseable mantener este número bajo).

6. Revise sus estadísticas para ver quién está resolviendo realmente los Incidentes, a fin de ver si alguno de los empleados está trabajando por debajo de sus posibilidades. Use estos datos con cuidado: puede que los que resuelven menos se encarguen de Incidentes más complejos.

Haga hincapié a su personal de la importancia de resolver Incidentes, y considere publicar diariamente una lista de Incidentes pendientes en el tablón de anuncios o en otra posición destacada.

Considere formar un equipo especial dedicado a resolver los Incidentes “pendientes” que ha identificado. En el caso de Linda, es poco probable que el equipo sea de más de dos personas. Aquí pongo énfasis en la palabra “considere”, ya que también podría decidir dejar los Incidentes a los ingenieros que actualmente se encargan de ellos.

9. Los Incidentes se asignarán a equipos y a agentes. Examine el reparto de Incidentes entre ellos (un gráfico de barras puede ser útil para ésto). Si nota cuellos de botella (por ejemplo, 300 Incidentes asignados a un individuo) tome medidas para redistribuir Incidentes como sea
necesario.

Algunas de estas sugerencias pueden dejar ver otros problemas. De ésos volveré a escribir en otro artículo.