Incident Management (Control del Proceso)

La correcta elaboración de informes forma parte esencial en el proceso de Gestión de Incidentes.

Incident Closed

Estos informes deben aportar información esencial para, por ejemplo:

  • La Gestión de Niveles de Servicio: es esencial que los clientes dispongan de información puntual sobre los niveles de cumplimiento de los SLAs y que se adopten medidas correctivas en caso de incumplimiento.
  • Monitorizar el rendimiento del Centro de Servicios: conocer el grado de satisfacción del cliente por el servicio prestado y supervisar el correcto funcionamiento de la primera línea de soporte y atención al cliente.
  • Optimizar la asignación de recursos: los gestores deben conocer si el proceso de escalado ha sido fiel a los protocolos preestablecidos y si se han evitado duplicidades en el proceso de gestión.
  • Identificar errores: puede ocurrir que los protocolos especificados no se adecuen a la estructura de la organización o las necesidades del cliente por lo que se deban tomar medidas correctivas.
  • Disponer de Información Estadística: que puede ser utilizada para hacer proyecciones futuras sobre asignación de recursos, costes asociados al servicio, etc.

Por otro lado una correcta Gestión de Incidentes requiere de una infraestructura que facilite su correcta implementación. Entre ellos cabe destacar:

  • Un correcto sistema automatizado de registro de incidentes y relación con los clientes
  • Una Base de Conocimiento (KB) que permita comparar nuevos incidentes con incidentes ya registrados y resueltos. Una (KB) actualizada permite:
    • Evitar escalados innecesarios.
    • Convertir el “know how” de los técnicos en un activo duradero de la empresa.
    • Poner directamente a disposición del cliente parte o la totalidad de estos datos (a la manera de FAQs) en una Extranet. Lo que puede permitir que a veces el usuario no necesite siquiera notificar la incidencia.
  • Una CMDB que permita conocer todas las configuraciones actuales y el impacto que estas puedan tener en la resolución del incidente.

Para el correcto seguimiento de todo el proceso es indispensable la utilización de métricas que permitan evaluar de la forma más objetiva posible el funcionamiento del servicio. Algunos de los aspectos clave a considerar son:

  • Número de incidentes clasificados temporalmente y por prioridades.
  • Tiempos de resolución clasificados en función del impacto y la urgencia de los incidentes.
  • Nivel de cumplimiento del SLA.
  • Costes asociados.
  • Uso de los recursos disponibles en el Centro de Servicios.
  • Porcentaje de incidentes, clasificados por prioridades, resueltos en primera instancia por el Centro de Servicios.
  • Grado de satisfacción del cliente.

Operation Management (Objetivos)

Los clientes cada vez más frecuentemente demandan un soporte al servicio de alta calidad, eficiente y continuo e independiente de su localización geográfica.

Es esencial para el buen desarrollo del negocio que los clientes y usuarios perciban que están recibiendo una atención personalizada y ágil que les ayude a:

  • Resolver rápidamente las interrupciones del servicio.
  • Emitir peticiones de servicio.
  • Informarse sobre el cumplimiento de los SLAs.
  • Recibir información comercial en primera instancia.

El punto de contacto con el cliente puede tomar diversas formas dependiendo de la amplitud y profundidad de los servicios ofrecidos:

  • Call Center: Su objetivo es gestionar un alto volumen de llamadas y redirigir a los usuarios, excepto en los casos más triviales, a otras instancias de soporte y/o comerciales.
  • Centro de Soporte (Help Desk): Su principal objetivo es ofrecer una primera línea de soporte técnico que permita resolver en el menor tiempo las interrupciones del servicio.
  • Centro de Servicios (Service Desk): representa la interfaz para clientes y usuarios de todos los servicios TI ofrecidos por la organización con un enfoque centrado en los procesos de negocio. Aparte de ofrecer los servicios citados anteriormente ofrece servicios adicionales a clientes, usuarios y la propia organización TI tales como:
    • Supervisión de los contratos de mantenimiento y niveles de servicio.
    • Canalización de las Peticiones de Servicio de los clientes.
    • Gestión de las licencias de software.
    • Centralización de todos los procesos asociados a la Gestión TI.

Los principales beneficios de una correcta implementación del Centro de Servicios se resumen en:

  • Reducción de costes mediante una eficiente asignación de recursos.
  • Una mejor atención al cliente que repercute en un mayor grado de satisfacción y fidelización del mismo.
  • Apertura de nuevas oportunidades de negocio.
  • Centralización de procesos que mejoran la gestión de la información y la comunicación.
  • Soporte al servicio proactivo.

Esta gestión no deja de ser el correcto proceso de la gestión de incidencias / cambios / peticiones.

Escalate incident process

Make a decision to escalate incident

Incident Management (Resolución)

En primera instancia se examina el incidente con ayuda del “Manual de Gestión de Incidencias” para determinar si se puede identificar con alguna incidencia ya resuelta y aplicar el procedimiento asignado.

Si la resolución del incidente se escapa de las posibilidades del Primer Nivel éste re direcciona el mismo a un nivel superior para su investigación por los expertos asignados. Si estos expertos no son capaces de resolver el incidente se seguirán los protocolos de escalado predeterminados.

Escalate incident process

Durante todo el ciclo de vida del incidente se debe actualizar la información almacenada en las correspondientes bases de datos para que los agentes implicados dispongan de cumplida información sobre el estado del mismo.

Si fuera necesario se puede emitir una Petición de Cambio (RFC). Si la incidencia fuera recurrente y no se encuentra una solución definitiva al mismo se deberá informar igualmente a la Gestión de Problemas para el estudio detallado de las causas subyacentes.

Cuando se haya solucionado el incidente se:

  • Confirma con los usuarios la solución satisfactoria del mismo.
  • Incorpora el proceso de resolución a la KB.
  • Reclasifica el incidente si fuera necesario.
  • Actualiza la información en la CMDB sobre los elementos de configuración (CI) implicados en el incidente.
  • Cierra el incidente.

Proceso Gestión de Incidencias

Incident Management Global Process 2012

Incident Management (Clasificación)

Es moneda frecuente que existan múltiples incidencias concurrentes por lo que es necesario determinar un nivel de prioridad para la resolución de las mismas.

El nivel de prioridad se basa esencialmente en dos parámetros:

  • Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.
  • Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA.

Service Level Categories

También se deben tener en cuenta factores auxiliares tales como el tiempo de resolución esperado y los recursos necesarios: los incidentes “sencillos” se tramitarán cuanto antes.

Dependiendo de la prioridad se asignarán los recursos necesarios para la resolución del incidente.

How do we make the decision on the priority

How do we make the decision on the priority

La prioridad del incidente puede cambiar durante su ciclo de vida. Por ejemplo, se pueden encontrar soluciones temporales que restauren aceptablemente los niveles de servicio y que permitan retrasar el cierre del incidente sin graves repercusiones.

Es conveniente establecer un protocolo para determinar, en primera instancia, la prioridad del incidente.

Expected Values

Change Management (Objetivos)

Vivimos en una época de continuos cambios. Tendemos a asociar la idea de cambio con la de progreso, y aunque esto no sea necesariamente así, es evidente que toda “evolución a mejor” requiere necesariamente de un cambio.

Sin embargo, es moneda frecuente encontrarse con gestores de servicios TI que aún se rigen por el lema: “si algo funciona, no lo toques”. Y aunque bien es cierto que el cambio puede ser fuente de nuevos problemas, y nunca debe hacerse gratuitamente sin evaluar bien sus consecuencias, puede resultar mucho más peligroso el estancamiento en servicios y tecnologías desactualizados.

Las principales razones para la realización de cambios en la infraestructura TI son:

  • Solución de errores conocidos.
  • Desarrollo de nuevos servicios.
  • Mejora de los servicios existentes.
  • Imperativo legal.

El objetivo primordial de la Gestión de Cambios es que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.

La Gestión de Cambios debe trabajar para asegurar que los cambios:

  • Están justificados.
  • Se llevan a cabo sin perjuicio de la calidad del servicio TI.
  • Están convenientemente registrados, clasificados y documentados.
  • Han sido cuidadosamente testeados en un entorno de prueba.
  • Se ven reflejados en la CMDB.
  • Pueden deshacerse mediante planes de “retirada del cambio” (back-outs) en caso de un incorrecto funcionamiento tras su implementación.

Los principales beneficios derivados de una correcta gestión del cambio son:

  • Se reduce el número de incidentes y problemas potencialmente asociados a todo cambio.
  • Se puede retornar a configuraciones estables de manera sencilla y rápida en caso de que el cambio tenga un impacto negativo en la estructura TI.
  • Se reduce el número de “back-outs” necesarios.
  • Los cambios son mejor aceptados y se evitan “tendencias inmovilistas”.
  • Se evalúan los verdaderos costes asociados al cambio y por lo tanto es más sencillo valorar el retorno real a la inversión.
  • La CMDB está correctamente actualizada, algo imprescindible para la correcta gestión del resto de procesos TI.
  • Se desarrollan procedimientos de cambio estándar que permiten la rápida actualización de sistemas no críticos.

La implementación de una adecuada política de gestión de cambios también se encuentra con algunas serias dificultades:

  • Los diferentes departamentos deben aceptar la autoridad de la Gestión de Cambios sobre todo en lo que respecta al cambio, independientemente de que este se realice para solucionar un problema, mejorar un servicio o adaptarse a requisitos legales.
  • No se siguen los procedimientos establecidos y, en particular, no se actualiza correctamente la información sobre los CIs en la CMDB.
  • Los encargados de la Gestión de Cambios no conocen a fondo las actividades, servicios, necesidades y estructura TI de la organización incapacitándoles para desarrollar correctamente su actividad.
  • Los Gestores del Cambio no disponen de las herramientas adecuadas de software para monitorizar y documentar adecuadamente el proceso.
  • No existe el compromiso suficiente de la dirección por implementar rigurosamente los procesos asociados.
  • Se adoptan procedimientos excesivamente restrictivos que dificultan la mejora o por el contrario el proceso de cambio se trivializa provocando una falta de estabilidad necesaria para la calidad del servicio.

Para esto hemos definido un proceso que nos permite gestionar el cambio de una manera estandarizada y lo más eficaz posible, a través de las diferentes fases del mismo.

Proceso de Gestión de Cambios

How to envolve a change between different phases

Incident Management (Objetivos)

Los objetivos principales de la Gestión de Incidentes son:

  • Detectar cualquiera alteración en los servicios TI.
  • Registrar y clasificar estas alteraciones.
  • Asignar el personal encargado de restaurar el servicio según se define en el SLA correspondiente.

Esta actividad requiere un estrecho contacto con los usuarios, por lo que el Centro de Servicios (Service Desk o Primer Nivel del Servicio (L1)) debe jugar una papel esencial en el mismo.

Aunque el concepto de incidencia se asocia naturalmente con cualquier malfuncionamiento de los sistemas de hardware y software según el libro de Soporte del Servicio de ITIL un incidente es:

Cualquier evento que no forma parte de la operación estándar de un servicio y que causa, o puede causar, una interrupción o una reducción de calidad del mismo”.

Por lo que casi cualquier llamada al Centro de Servicios puede clasificarse como un incidente, lo que incluye a las Peticiones de Servicio tales como concesión de nuevas licencias, cambio de información de acceso, etc. siempre que estos servicios se consideren estándar.

Cualquier cambio que requiera una modificación de la infraestructura no se considera un servicio estándar y requiere el inicio de una Petición de Cambio (RFC) que debe ser tratada según los principios de la Gestión de Cambios.

Los principales beneficios de una correcta Gestión de Incidentes incluyen:

  • Mejorar la productividad de los usuarios.
  • Cumplimiento de los niveles de servicio acordados en el SLA.
  • Mayor control de los procesos y monitorización del servicio.
  • Optimización de los recursos disponibles.
  • Una CMDB (ESL) más precisa pues se registran los incidentes en relación con los elementos de configuración.
  • Y principalmente: mejora la satisfacción general de clientes y usuarios.

Por otro lado una incorrecta Gestión de Incidentes puede acarrear efectos adversos tales como:

  • Reducción de los niveles de servicio.
  • Se dilapidan valiosos recursos: demasiada gente o gente del nivel inadecuado trabajando concurrentemente en la resolución del incidente.
  • Se pierde valiosa información sobre las causas y efectos de los incidentes para futuras reestructuraciones y evoluciones.
  • Se crean clientes y usuarios insatisfechos por la mala y/o lenta gestión de sus incidentes.

Las principales dificultades a la hora de implementar la Gestión de Incidentes se resumen en:

  • No se siguen los procedimientos previstos y se resuelven las incidencias sin registrarlas o se escalan innecesariamente y/o omitiendo los protocolos preestablecidos.
  • No existe un margen operativo que permita gestionar los “picos” de incidencias por lo que éstas no se registran adecuadamente e impiden la correcta operación de los protocolos de clasificación y escalado.
  • No están bien definidos los niveles de calidad de servicio ni los productos soportados. Lo que puede provocar que se procesen peticiones que no se incluían en los servicios previamente acordados con el cliente.

Para ellos tenemos definido un proceso, estándar, que nos puede servir de guía en la gestión de incidencias.

Proceso Gestión de Incidencias

Incident Management Global Process 2012