Identificación y descripción de las actividades

En el siguiente Flujograma, se detallan las actividades que se describen en este epígrafe. Está en inglés, que, en el mundo de las redes telemáticas y en las TI en general, es el idioma en el que suelen estar escritos los manuales, por lo que es conveniente familiarizarse con el vocabulario.

Flujograma de las actividades realizadas en la gestión de incidencias

Identificación

Para poder saber lo que se debe tratar como Incidencia, lo primero es saber identificarla, algo que no es obvio aunque lo parezca. Es importante tener en cuenta para esta identificación lo siguiente:

• Conocer su definición.
• Saber cuáles son los requisitos mínimos de funcionamiento de la red que se está administrando. Así pues, será necesario tener las especificaciones que se acuerdan a la hora de diseñar la red y en las que se establecen estos requisitos mínimos de continuidad y Calidad del servicio (SLA o ANS). En este caso, estas especificaciones es conveniente que se conozcan a todos los niveles de gestión, tanto a primer nivel como a niveles jerárquicos superiores.
• En caso de duda, serán los recursos humanos según jerarquía los que decidan si debe tratarse como tal, es decir, si se considera Incidencia y de qué tipo es.

Con todo esto, se debería conocer e identificar el Evento que llega y ser capaz de clasificarlo como Incidencia o no.

Pero, a pesar de todo lo explicado anteriormente, hay una cosa más importante a tener en cuenta: lo que realmente delimita e identifica una Incidencia es lo que el grupo de trabajo o las personas que administran esta gestión de incidencias consideran como tal. Tanto es así que, en la actualidad, se ha generalizado el tratamiento de incidencias a otras facetas de las TI.

Una vez que se considera el Evento en concreto como una Incidencia, normalmente se le asigna un número identificativo y se sigue con el proceso.

Recordemos! En la actualidad, la gestión de incidencias se usa para tratar todo tipo de eventos en la red, por su alta eficacia y buenos resultados.

Registro

Se registra un incidente cuando se guarda en una base de datos, programa web o cualquier herramienta usada para este fin. El hecho de registrarlo se considera de vital importancia en metodologías, manuales de buenas prácticas y programas de gestión actualmente. Esto es así por varios motivos:

• Para poder monítorizar la progresión de la Incidencia.
• Ayuda al diagnóstico de los que aparecen nuevos.
• Se pueden priorizar y, al estar registrado, no se pierden los menos importantes.
• Si se da un número grande de llamadas, se puede hacer una estadística del impacto que causa.
• Se evita una posible concurrencia a la hora de la resolución y se da una mejor gestión.

Al registrar una Incidencia, se observan los siguientes pasos:

• Relacionar en la herramienta de Registro el número o la identificación asignada. Puede ser que el sistema lo haga automáticamente.
• Registro de la Información básica por la que se ha detectado el posible fallo, falta o reducción de servicio.
• Posteriormente, se van detallando, si es posible, las Acciones requeridas para la solución, dentro del mismo sistema de Registro.

Clasificación

Para poder tratar y resolver una Incidencia, es importante hacer una buena clasificación de esta, para posteriormente priorizarla y escalarla. Para esto, el personal que recibe la Incidencia debe conocer las especificaciones de la red. Así, para poder clasificarlo, debe tener un análisis previo, aunque no sea exhaustivo. Esto será clave para la posterior priorización.

La clasificación del Incidente depende de muchos factores y se deben consensuar por el grupo de trabajo. Así, so puede clasificar según:

• Área de impacto: a qué clientes afecta (puede ser una red local, una red de clientes), a qué servicios, etc.
• Nivel de impacto: es muy importante conocer el impacto que tendrá sobre los clientes y los niveles mínimos estipulados. Así, si afecta a una subred muy amplia, no será igual que a una pequeña dentro de la misma red.
• Categoría: está bastante interrelacionada con el nivel de impacto. Se refiere al tipo de servicio que se deja de dar cuando ocurre la Incidencia. Hay servicios más críticos y servicios menos críticos.

Ejemplo: dentro de una empresa de venta de una tienda de deportes por Internet, tienen servicio de correo electrónico, tienda on-line y acceso a proveedores. El impacto que tiene una caída temporal de la tienda en sí, la que se dedica a la venta on-line, es mayor que la caída al acceso a proveedores, ya que el coste de imagen es importante y si los clientes no pueden acceder a la página se puede, aparte de perder esa venta, dar una mala imagen que repercutirá en ventas posteriores. Sin embargo, el acceso a proveedores no es urgente en el tiempo, porque se puede acceder más tarde sin una alta repercusión para el negocio.

• Urgencia: aunque a veces las incidencias no son tan importantes, sí se puede encontrar que sean urgentes, porque aunque el servicio que falla no sea crítico, puede ser algo que se debe resolver en el momento, porque causa otro tipo de perjuicios en el servicio que hacen que se tenga que considerar una cierta urgencia en la resolución.
• Estado actual: el estado puede ir cambiando en el tiempo. Puede cambiar la prioridad o la urgencia de una gestión de incidentes a lo largo del tiempo, por las Acciones que se vayan haciendo. Por ejemplo: si se ha dado una solución temporal en la que se restaura el servicio, la clasificación y la prioridad de la Incidencia cambia. Así que depende del estado en que se encuentre en ese momento.

Aunque estos son los principales factores para la clasificación de una Incidencia, puede haber más que la empresa o el personal encargado consideren. Depende mucho del tipo de empresa y de la red a gestionar. Por ejemplo: puede haber una clasificación por áreas de trabajo, porque sea una empresa grande que tenga grupos que se dediquen a distintas cosas.

Ejemplo:

Normalmente, en las grandes empresas suele haber departamentos que se dedican al hardware y al software de las redes y de los sistemas independientemente, aunque, por supuesto, tienen que interrelacionarse y trabajar conjuntamente en muchos casos. Esta sería otra posible clasificación de las incidencias.

Por último, cabe señalar que la clasificación de las incidencias es algo que se mantiene vivo durante la gestión y la resolución, es decir, es algo que va cambiando según se va tratando la Incidencia.

Priorización

Una vez clasificada la Incidencia, el siguiente paso es priorizarla y depende mucho de la clasificación que se haya hecho, así que depende de la del área de impacto, del nivel de impacto, de la categoría, de la urgencia y del estado actual.

Para poder priorizar correctamente una Incidencia, son realmente importantes dos cosas:

• Impacto: con este parámetro se mide el efecto que tiene el incidente en la red y en todas las aplicaciones que conlleva.
• Urgencia: medida para conocer qué tiempo tarda en tener un efecto negativo en las aplicaciones de la red y en el negocio en general la Incidencia.

Así, la prioridad estará basada en este impacto y en esta urgencia, porque, dependiendo de ellos, será más o menos prioritario su escalado y su resolución.

Como se prioriza un incidente

• Impacto: es una medición del efecto de un incidente, un problema o un cambio en los Procesos del negocio
• Urgencia: es una medición de cuánto tiempo tarda un incidente, un problema, o un cambio en tener impacto significativo en el negocio

Por ejemplo: un incidente de alto impacto puede tener una urgencia baja, si el impacto no afectara el negocio hasta el siguiente año financiero

• Prioridad: es una categoría utilizada para identificar la importancia relativa de un incidente, un problema, o un cambio
• Una prioridad está basada en un impacto y urgencia, y es utilizada para identificar el tiempo que se necesita para que las Acciones se llevan a cabo

Por ejemplo: los recuerdos del nivel del servicio (SLA) pueden decir que los incidentes de prioridad 2 deben ser resueltos en un lapso de 12 horas

Pero, además, para priorizarla, se deben tener en cuenta los siguientes factores:

• Concurrencia: es importante conocer qué otros incidentes se están dando en el mismo momento, esto hará que la gestión de la Incidencia sea inmediata o no.
• Recursos disponibles: dependiendo de los recursos tanto humanos como tecnológicos disponibles en el momento de la recepción de la Incidencia, se priorizará más o menos.
• Posibles problemas derivados de este incidente que puedan llevar a algo más grave: si en un primer análisis se puede prever que, si no se soluciona en un tiempo razonable, puede ocurrir algo más grave.

Pero, para priorizar la Incidencia, lo más importante es la clasificación inicial.

También hay que tener en cuenta que la priorización de un incidente puede ir cambiando con el tiempo, porque los factores que lo determinan también varían.

Diagnóstico inicial

Una vez que se tiene clasificada y priorizada una Incidencia, se debe hacer un estudio inicial para poder realizar un diagnóstico. En las metodologías y manuales de buenas prácticas para la gestión de incidencias, se describen distintos niveles para esta gestión. Así, dependiendo de la gravedad y complejidad de un incidente, hay distintos recursos técnicos y especialmente humanos para manejar el asunto. Por lo tanto, es importante realizar este estudio inicial. Para esto, los recursos humanos, que están en el primer nivel de atención al incidente, deben tener unos mínimos conocimientos de herramientas y metodologías y, por otro lado, de la organización y definición de la red para realizar un estudio básico inicial.

Este diagnóstico inicial vendrá dado por el departamento que se encargue de recibir la Incidencia en primera instancia. En las metodologías actuales y en los manuales de buenas prácticas se describe el departamento Service Desk o Centro de Servicio al Usuario (SD). Este realizaría normalmente este diagnóstico inicial, para así poder escalarlo al departamento correspondiente. Este departamento es de vital importancia en metodologías como ITIL.

Service Desk o Centro de Servicio al Usuario

Escalado

Es conveniente tener distintos niveles para la gestión de incidencias, de problemas y/o de peticiones de usuario. De esta manera, será mucho más eficiente el trabajo y la gestión sobre estos. Así pues, una vez clasificada, identificada, registrada y priorizada la Incidencia junto al diagnóstico inicial, se puede empezar a trabajar sobre ella para buscar una posible solución.

Dependiendo de la dificultad y la repercusión que haya tenido el posible fallo sobre la red y, por consiguiente, sobre los servicios que esta ofrece, se podrá resolver en el primer nivel, sobre todo si hay una base de datos en donde se registren todos los fallos anteriores o actualizaciones. Si es posible, se arreglará y, si no, se escalará a otro nivel.

De esta manera, habrá distintos niveles, especialmente de recursos humanos, con distintos campos de conocimiento. Si el problema no se puede resolver, se deberá redirigir la gestión a niveles más avanzados de conocimiento o a áreas distintas dentro de la misma organización.

En la siguiente imagen, se puede observar un Flujograma de cómo se realiza el escalado de incidencias a distintos departamentos o distintas jerarquías. Así, si un incidente es analizado y al final no se consigue resolver, se tendrá que estudiar el caso de escalarlo a un departamento distinto:

Escalado de incidencias

Investigación y diagnóstico

Una vez que ya está clasificada la Incidencia y en el departamento adecuado, se debe empezar a trabajar con ella. Evidentemente, este trabajo debe ser realizado por el personal competente y depende de la naturaleza y del impacto de la Incidencia.

Por eso, aunque parezcan tediosos y trabajosos todos los pasos que se han dado al recibir la Incidencia, es importante hacerlos, porque de una buena clasificación (contando con el Registro, identificación, etc.) depende que la investigación y el diagnóstico se realicen en el lugar adecuado. Y esto al final reduce tiempo y costes.

Esta fase se puede repetir varias veces, hasta que se acerque al resultado esperado u óptimo.

Para esta fase, hay que tener en cuenta que los problemas se pueden derivar de muchas causas:

• Puede haber un problema hardware en la red.
• Puede ser un problema software de la red.
• Puede haber un error de documentación.
• Puede ser un error humano.
• Puede ser un error del Procedimiento.
• Puede ser un error de la infraestructura.

Lo que sí que hay que tener en cuenta es que, aunque en principio no parece obligatorio, es importante tener una documentación y una base de datos sobre lo que ocurre. Todos los manuales lo recomiendan fehacientemente. Esto es porque, aunque no sean las mismas incidencias las ocurridas cada vez, es muy útil conocer otras parecidas y ver cómo se han resuelto.

Importante! Los pasos anteriores al diagnóstico (clasificación, diagnóstico inicial, escalado, etc.) son realmente importantes, porque de ellos depende que esta investigación se realice en el departamento adecuado, reduciendo tiempos y costes innecesarios.

Si el departamento inicial o el departamento o personal al que se ha escalado la Incidencia no consiguen realizar un diagnóstico completo porque no les compete lo que pasa, se realiza el estudio y, con una justificación, se puede escalar a otro departamento superior o de otra especialidad, dependiendo del diagnóstico al que se haya llegado después de la investigación.

Investigación en los distintos departamentos

Resolución y recuperación

En esta fase, se le da al cliente una solución al problema. Cuando se ha determinado la causa, es más fácil llegar a esta solución. En algunas metodologías, a esto le llaman Error conocido. Hasta el momento de la investigación, hay un error y no se sabe lo que es, por lo que no se le puede dar una solución. Cuando se realiza la investigación y el diagnóstico y se pasa a esta fase, hay que tener ya un Error conocido que se pueda solucionar.

Pero también se puede llegar a esta fase antes de tener un diagnóstico bueno. Hay casos en que, dependiendo de las especificaciones pactadas con el cliente y del impacto de la Incidencia, se debe dar una solución temporal, aunque no sea totalmente correcta. Esto ocurrirá cuando la solución definitiva requiera de más tiempo de trabajo, de una actualización completa o de algo más complejo. Habrá que tomar una serie de medidas, entre ellas esta solución temporal. Evidentemente, se sabrá cuál es el error (será un Error conocido también), pero la solución no será tan evidente.

Tanto en el caso de haber dado una solución temporal como el caso en el que se da la solución definitiva, se debe recuperar en la medida de lo posible la red y los sistemas que dependen de esta y, por supuesto, avisar al cliente para que pueda hacer uso de la red, dentro de las posibilidades que le ofrezca esta solución.

Otra cosa a tener en cuenta es que, en la mayoría de los casos, sobre todo en las grandes empresas, que son las que suelen trabajar con las metodologías de la gestión de incidencias, el departamento en el que se gestiona la solución a este error de la red es probablemente un departamento distinto al que ha trabajado hasta este punto en las actividades anteriores. Por este motivo, es importante tener todo muy bien estudiado y documentado, para no crear posibles retrasos en el proceso completo.

Cierre

Para cerrar la gestión de una Incidencia, hay que tener en cuenta distintos aspectos. No se puede cerrar a no ser que se tenga absolutamente claro que ha sido solucionada y el personal de resolución y recuperación den el visto bueno sobre la puesta en marcha de la red de manera que cumpla completamente los requisitos de las especificaciones.

Así, las actividades que habría que tener en cuenta para el cierre de una Incidencia serían:

• Tener el visto bueno de los departamentos o personas que han dado el diagnóstico y la solución de la Incidencia.
• Informar al cliente de la solución y recuperación de la red y de los servicios prestados por esta. Informar del fallo y de la solución y explicarle si puede volver a darse o no.
• Repasar toda la Información que conlleva esta gestión de la Incidencia. Comprobar que se han dado todos los pasos que se han descrito. Comprobar que todo el personal puede estar informado del desarrollo y tiempo de vida de la Incidencia.
• Registrar toda la Información que no haya sido registrada, sobre el diagnóstico, la investigación la resolución y el cierre. Este paso es muy importante para la optimización de posteriores incidencias o problemas que surjan, bien por esta misma Incidencia o bien por otras distintas y nuevas.
• Informar a los departamentos que se encargan de la mejora de la Calidad y el estudio de posibles errores, por si es necesaria una posterior investigación para evitar que vuelva a ocurrir.

Cierre de la gestión de incidencias

No se debe dejar una Incidencia abierta si se ha resuelto, porque esto puede llevar a errores, a pérdida de tiempo y a costes innecesarios. Hay un caso excepcional en el que se puede cerrar una Incidencia sin haberla resuelto completamente, si se da el caso de que después del estudio e intento de solución del error de la red se llega a la conclusión de que no se puede solucionar ese error en concreto. Se cerraría la Incidencia y se registraría como sin posible solución o quizá la solución sería un cambio o una actualización completa de la red y así se especificaría en el cierre.