Gestión de la incidencia crítica

0

Si algo no se te olvida como profesional de la gestión de servicios es la primera vez que te enfrentas a una incidencia crítica. La gente corre, se grita de una mesa a la otra, “¿Has mirado si está levantado el router?”, “No consigo ni hacer login.”, “¿Ha ido alguien al CPD?”. Una incidencia crítica que parece no resolverse es uno de esos momentos que le dan vidilla al trabajo. Sobretodo cuando el CIO empieza a sobrevolar por la zona. ¡Qué digo el CIO! Lo realmente divertido es cuando empieza a bajar gente de negocio histérica o incluso el CEO. Eso sí que te da una historia para contar luego a los nietos.

Está claro que una incidencia crítica es algo que se sale de lo común, por lo que su gestión también debe ser diferente a lo común. Pero, empecemos por el principio y definamos lo que es una incidencia crítica.

¿Qué es una incidencia crítica?

Es una incidencia con un gran impacto en el negocio, en el que su resolución pasa a ser lo más prioritario para todo el equipo de TI. Hablamos de incidencias como caídas de sistemas críticos, pérdidas de red completas o errores de software que suponen un gran gasto para la organización. No hablamos de casos que ponen en peligro la continuidad del negocio, es son desastres. Un desastre es algo que puede llegar a acabar con el negocio, como un incendio en el CPD. Una incidencia crítica no pone en peligro la continuidad del negocio, pero si que le impacta de forma considerable.

Como ya os dije en el artículo sobre priorización de incidencias, una manera fácil de definir una incidencia crítica como aquellas en las que la alta dirección quiere estar informada. Si le importa al CEO, es que es crítica.

Otro aspecto importante con el que no hay que confundir el término de incidencia crítica es con el concepto de incidencia masiva. Una incidencia masiva es una incidencia que está afectando a un gran número de usuarios. Aunque es verdad que muchas incidencias críticas son masivas, una incidencia masiva puede no ser crítica (el correo se retrasa 10 minutos en llegar a todos nuestros empleados) y una incidencia crítica puede no ser masiva (la integración con el TPV Virtual de una web de venta on-line no está funcionando).

Tampoco hay que confundir una incidencia crítica con un problema muy grave. Una incidencia crítica suele resolverse en minutos u horas. Un problema grave puede durar semanas.

Los procedimientos no valen

Antes de que el lector se me eche al cuello, hablo de los procedimientos estándar. En una incidencia crítica el procedimiento estándar, sobretodo en organizaciones con una gestión de incidencias madura, no es el adecuado. Necesitamos libertad en la actuación, rapidez y añadir una serie de pasos.

Lo mejor es tener un procedimiento aparte, o una modificación al procedimiento estándar. Yo me suelo decantar por lo segundo (bueno, solía, porque mi etapa como consultor de servicios parece acabada). Es decir, defino todo el procedimiento de gestión de incidencias y añado un capítulo sobre consideraciones especiales en el caso de incidencias críticas.

Consideraciones especiales

Ahora viene lo que creo que es la chicha de este artículo, mis consejos sobre qué debe incluir esta modificación al procedimiento estándar:

  • Hay que incluir un método claro sobre cuándo estamos delante de una incidencia crítica o de alta prioridad. Puede ser algo tan simple como marcar una casilla en nuestra herramienta de gestión de TI, o el envío de un mail por parte de un responsable en concreto (o miembro de un grupo) anunciándolo. Aquí no debe haber medias tintas: o es crítica o no. Nada de “medio-crítica”.
  • Debe nombrarse un responsable. Y debería ser alguien con autoridad. Es muy común que una incidencia crítica afecte a varios grupos en TI y en negocio. Debe existir una figura de referencia para toda la organización y para la toma de decisiones. Si no, correremos el riesgo de que ningún grupo mueva ficha durante un tiempo creyendo que otro está en ello, retrasando la resolución.
  • El responsable seguirá continuamente la evolución de la resolución. Y todos le irán informando de lo que encuentran. Nada de líberos jugando en solitario.
  • El responsable comunicará a la organización la incidencia crítica (si es crítica, les importará a casi todos). Y les mantendrá informados regularmente.
  • Las normativas de documentación sobre incidencias, es decir, ir escribiendo en el ticket de turno lo que sucede, pasa a segundo plano. Eso sí, una vez resuelto, se redacta.
  • Tras la incidencia crítica el responsable convoca una reunión, que puede ser corta, en un plazo breve desde el suceso de la incidencia, para revisar el por qué y qué medidas adoptar para que no vuelva a pasar.

Resumen

Debemos tener un procedimiento especial para incidencias críticas que incluya un responsable, control, comunicación y revisión.

 

 

 

About author

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 y va en camino de certificarse como PMP. 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 Idiso, empresa de servicios de distribución hotelera, como responsable del equipo de desarrollo web.

No comments

Te puede interesar...