IT-OPs-01. Process Owner Operaciones IT / Leandro Cinti

Proceso de Gestión de Incidentes IT&S IT-OPs-01

Process Owner

Operaciones IT / Leandro Cinti

Registro de Cambios

Versión Descripción Autor Area Fecha de

creación

Revisado por 1.0 Proceso de Gestión de

Incidentes IT&S

Paula Sajoux Dirección IT&S 15/1/19 Leandro Cinti, Hernan Chao Observaciones Leandro Gorriz y

Alejandro Gonzalez Calderón

Gcia Desarrollo IT

28/1/19

Aprobación Leandro Cinti Dirección IT&S 6/8/2019

2

Contenido

Alcance ... 3

Situación actual ... 3

Pre-Condiciones ... 3

Definiciones ... 3

Incidente... 3

Gestión de Incidentes ... 4

Actores / Roles ... 4

Flujo de Proceso ... 6

Descripción detallada de tareas ... 7

Matriz RACI ... 12

Métricas... 14

Normativa Asociada ... 14

ANEXO I ... 15

Prioridad de los Incidentes ... 15

ANEXO II: ... 17

Template de comunicaciones de incidentes críticos ... 17

Objetivo

El presente documento tiene como finalidad detallar el Proceso de Gestión de Incidentes de Sistemas y Tecnología, cuyo objetivo es restaurar la operación normal del servicio afectado lo más rápido posible, minimizando el impacto en el negocio y asegurando que se mantengan los niveles acordados de calidad y disponibilidad.

Alcance

Comprende las actividades que están vinculadas al proceso de Gestión de Incidentes de Sistemas y Tecnología de VUCE.

Situación actual

N/A

Pre-Condiciones

Del proceso

• El Proceso de Gestión de Incidentes - Mesa de Ayuda de VUCE derive los casos técnicos.

• El sistema de monitoreo detecta una alarma que corresponde a un incidente.

Definiciones

Incidente

Se considera incidente a cualquier evento que no es parte de la operación normal de un Servicio / Sistema de IT. Se considera incidente, también, a toda Interrupción no planificada o reducción en la Calidad de un Servicio de TI. Pueden tener impacto en el Servicio / Sistema, aunque el mismo puede ser leve y resultar transparente para los usuarios (ejemplo: fallo de un Elemento de Configuración que no ha impactado todavía en el Servicio, el fallo de uno de los discos de un

“mirror”).

Es importante remarcar la diferencia entre los siguientes conceptos:

• Un incidente es “cualquier evento que no es parte de la operación estándar de un servicio y el cual causa o puede causar una interrupción o reducción en la calidad del

4

• Un problema es una condición identificada desde múltiples incidentes exhibiendo síntomas comunes, o de un incidente individual, con origen en un error individual pero cuya causa es desconocida.

• Un error conocido es una condición identificada por un diagnóstico de la causa raíz de un problema y el consiguiente desarrollo de una solución.

Gestión de Incidentes Actores / Roles

Dueño del Proceso:

- Es el responsable de que se cumpla el proceso, de su diseño, actualización, entrenamiento del personal.

- Es responsable de garantizar que su proceso se esté realizando de acuerdo con el proceso acordado, documentado y que se estén cumpliendo los objetivos de la definición del proceso.

- Responsabilidades:

• Documentar y publicar el proceso.

• Definir las métricas para evaluar la efectividad y eficiencia del proceso.

• Analizar las métricas para ejecutar las acciones correctivas necesarias.

• Responsable del diseño del proceso.

• Mejor la eficiencia y eficacia del proceso y revisar las mejoras propuestas.

• Asegurar el entrenamiento de los que participan en el proceso y que cada uno tenga conciencia de su rol.

• Asegurar la existencia de revisiones y auditorias regulares del proceso, de sus roles y sus responsabilidades, y de la documentación correspondiente.

Gestor de Incidentes:

- Es el responsable de la gestión operacional de un proceso.

- Puede ser la misma persona que sea dueño y gestor del proceso.

- Coordina las actividades del proceso.

- Responsabilidades:

• Planificar y coordinar todas las actividades del proceso junto con el dueño.

• Asegurar que las actividades se realizan según se requiera durante el ciclo de vida del servicio.

• Asignar personal a los roles requeridos.

• Monitorear y reportar la performance el proceso.

• Identificar oportunidades de mejora.

• Implementar las mejoras del proceso.

• Definir la prioridad del incidente.

Operaciones IT:

Es el segundo nivel de soporte antes los incidentes técnicos: diagnostica las causas de eventuales interrupciones en los servicios y el procesamiento o transferencias de información, y ejecuta mecanismos de corrección (para restaurar el servicio) o escala a las áreas que correspondan.

Responsable de registrar y clasificar los incidentes detectados por monitoreo, y llevar a cabo esfuerzos inmediatos para restaurar lo antes posible un servicio de TI que ha fallado.

Si no se encuentra una solución adecuada a estos fines, refiere el incidente a grupos de apoyo técnico especializado (Soporte de Tercer Nivel).

Infraestructura IT

Es el técnico especialista o soporte de segundo nivel capaz de investigar en profundidad un incidente o requerimiento para entregar una solución al usuario final. Diagnostica fallas de hardware, conectividad y software de base y brinda soporte en la gestión de problemas con el proveedor o fabricante que corresponda.

Desarrollo de Sistemas

Es el técnico especialista o soporte de segundo nivel capaz de analizar en profundidad un incidente o requerimiento para proveer una solución al usuario final. Diagnostica fallas de software y de configuración de aplicaciones o servicios, y proporciona soporte en la gestión de problemas con el proveedor.

Contact Center

Es el primer nivel de soporte del usuario, el punto de contacto entre el usuario y VUCE.

Su responsabilidad es registrar y clasificar las llamadas, consultas y pedidos reportados y, de ser posible, resolver las mismas. Si no lo puede resolver debe derivar al grupo que pueda hacerlo.

Mesa de Ayuda Funcional

Es el soporte funcional y de negocio del sistema VUCE.

Soporte de Cuarto Nivel

Es el soporte del proveedor de hardware o software. Por ejemplo: Arsat (servidores e infraestructura), Modernización (base de datos, TAD/GDE), AFIP (servicios AFIP) o Aduana (servicios de SIM).

6

Flujo de Proceso

Descripción detallada de tareas

Registro y Tipificación 1. Registra de Incidente

Al identificar una alarma de Monitoreo se registra un incidente en la herramienta de Gestión de Incidentes con la siguiente categorización o tipificación:

- Origen ticket:

o Evento: cuando Operaciones IT detecta un incidente por medio de una alarma de monitoreo de Nagios.

o Contact Center: cuando lo genera la Mesa de Ayuda.

- Tipo: Otra consulta o reclamo - Motivo: Reclamo

- Relacionado con: VUCE (Ventanilla Única de Comercio Exterior) - Programa/Rubro relacionado: Dificultades técnicas

- Asunto: se completa con la tipificación del incidente según la siguiente lista:

o Indisponibilidad total o parcial del Sistema

o Baja performance/lentitud de algún modulo particular o general del sistema o Error aplicativo

o Problema de autenticación

Verificación inicial y Priorización 2. Verifica si Falta información

Analiza que el incidente contenga la información necesaria para el análisis y resolución del mismo.

Si le falta información realiza la actividad “Reasigna a nivel 1”, sino continúa con la actividad

"Verifica si es Reclamo o Incidente".

2.1 Reasigna a nivel 1

Reasigna el incidente al Soporte de Nivel 1 (quién lo registró) y se contacta con el Soporte Nivel 1 por mail y/o telefónicamente para avisarle que se requiere más información y que se le derivó el reclamo. Continúa con el proceso “Gestión de Incidentes - Mesa de Ayuda de VUCE”.

8 3. Verifica si es Reclamo / Incidente

Verifica que el ticket esté catalogado como “Reclamo” en el campo motivo y que el contenido del mismo corresponda a un incidente.

Si el mismo no es reclamo o incidente deriva el incidente a Soporte VUCE y continúa en el proceso

“Gestión de Mesa de Ayuda de VUCE”.

4. Define Prioridad

Evalúa la información del incidente y analiza los servicios afectados, componentes impactados, alcance del incidente, como así también su correcta tipificación. La prioridad de cada incidente es definida por el Gestor de Incidentes de acuerdo a la Urgencia y el Impacto del mismo. De ser necesario, el Gestor de Incidentes analizará el caso con el senior management de VUCE. En el Anexo I se encuentra la explicación del cálculo de la prioridad de los incidentes.

5. Actualiza Asunto con “Prioridad”

Actualiza en el incidente el campo Asunto agregando el texto “Prioridad CRITICA”, “Prioridad ALTA”,

“Prioridad Media” o “Prioridad BAJA”, según corresponda, al inicio del mismo (antes de la tipificación del incidente).

6. Si la Prioridad es crítica

6.1. Comunica apertura del Incidente Crítico

Los incidentes de prioridad críticos son comunicados por correo a los directores, gerentes, Mesa de Ayuda y Soporte de VUCE según el template del Anexo II.

Además se envía mensaje al celular de los directores y gerentes de VUCE informando la apertura del incidente crítico.

Investigación y Diagnóstico 7. Evalua/Analiza Incidente

El analista de incidentes dispara el proceso técnico de resolución con las áreas involucradas.

Para encaminar el diagnóstico, debe determinar, en una primera instancia, si el incidente se ocasiona por problemas en la infraestructura de IT o en la aplicación.

Para esta definición, utiliza como base la siguiente información:

- Descripción del usuario afectado en relación a los servicios que podrían estar fallando.

- Herramientas de monitoreo disponibles para chequear si hay algún impacto en la infraestructura o en los servicios aplicativos.

- Errores conocidos que hayan sido registrados previamente.

8. Si es un incidente de infraestructura: toma alguna de las siguientes acciones según corresponda:

• Si es de ARSAT: Abre ticket en ARSAT

• Si es PAEC, TAD, GDE o Servicio VUCE-TAD: Abre Ticket en Jira Modernización.

8.1. Actualiza el campo solución con el Nro. de Ticket gestionado: actualiza en el campo solución del incidente con el ticket generado en ARSAT o en Modernización.

8.2. Actualiza estado a “Espera respuesta”: actualiza el estado del incidente a “Espera respuesta”.

8.3. Recibe ticket resuelto: ARSAT o modernización avisan que el incidente fue resuelto.

Continúa con la actividad “Se pudo resolver el incidente”.

9. Busca la solución en base de Conocimientos VUCE

El analista de incidentes verifica en la Base de Conocimientos si existe una solución Error Conocido para el incidente reportado.

De no contar con una solución en la Base de Conocimiento, busca si hay un Workaround. De existir el workarround continúa con la actividad “Requiere gestionar Cambio” dentro de la fase de Resolución de Incidentes.

Si existe solución definida en la Base de Conocimiento, se analizará si la misma es aplicable para la resolución del incidente, en cuyo caso continúa con la actividad “Requiere gestionar Cambio” dentro de la fase Resolución de Incidentes.

10 9.1. Verifica si es Desarrollo

9.1.1. Analiza el incidente: evalúa la información del incidente y se analizan los servicios afectados, componentes impactados, alcance del incidente, como así también su correcta tipificación. Analiza sus posibles causas y acciones realizadas hasta el momento, para determinar un diagnóstico.

9.1.2. Registra ticket en Jira VUCE: registra el ticket para la resolución por parte del proveedor.

9.1.3. Requiere activar Soporte Proveedor: analiza si se requiere activar el soporte. Si no requiere Activar Soporte continua con la actividad “Elabora solución”.

9.1.3.1. Actualiza estado a “Espera respuesta”: actualiza el estado en el incidente.

9.1.4. Elabora solución: elabora la solución con el detalle de los pasos a realizar para remediar el inconveniente.

9.2. Si es Infraestructura

9.2.1. Analiza el incidente: evalúa la información del incidente y se analizan los servicios afectados, componentes impactados, alcance del incidente, como así también su correcta tipificación. Analiza sus posibles causas y acciones realizadas hasta el momento, para determinar un diagnóstico.

9.2.2. Requiere activar Soporte Proveedor: analiza si se requiere activar el soporte 9.2.2.1. Activa Soporte Proveedor: se comunica con el soporte quien analiza el

incidente. De ser necesario, el soporte actualiza el mismo.

9.2.3. Elabora solución: elabora la solución con el detalle de los pasos a realizar para solucionar el inconveniente.

Resolución y Recuperación

10. Requiere Gestionar Cambio

Si requiere gestionar cambios continúa con el “Proceso de Gestión de Implementación de Cambios IT&S”.

10.1. Implementa la solución

Se aplican las acciones de solución del incidente y de recuperación del servicio impactado, y se valida que las mismas sean efectivas.

11. Pudo resolver el incidente

Valida si se pudo resolver el incidente luego de la implementación de la solución.

Si el incidente no fue resuelto vuelve a la actividad “Evalua/Analiza Incidente”, sino continúa con la siguiente actividad.

11.1. Si el incidente es crítico “Comunica cierre de Incidente Crítico”: comunica el cierre del incidente por mensaje a los directores y gerentes de VUCE y, además, por correo a los directores, gerentes, Mesa de Ayuda y Soporte de VUCE según el template del Anexo II.

11.2. Documenta la solución y cambia estado a “Solucionado”

Documenta la solución en el Incidente y cambia el estado del mismo a “Solucionado”.

Cierre:

12. Requiere confirmación Mesa de Ayuda

Si el incidente se generó desde la Mesa de Ayuda, la misma debe verificar con el usuario la resolución del incidente.

12.1. Reasigna a nivel 1

Reasigna el incidente al usuario que se lo derivó de la Mesa de Ayuda, contacta al usuario de Mesa de Ayuda por teléfono y/o por mail para avisarle que requiere la conformidad del usuario y que le deriva el incidente. Continúa con el proceso “Gestión de Incidentes - Mesa de Ayuda de VUCE”.

13. Cierra el incidente

Se realizan las actividades necesarias para el cierre del incidente.

12

Matriz RACI

En esta matriz se asignan los roles que un recurso debe ejecutar, para cada actividad dada.

A continuación se describe la representación de cada una de las letras asignadas.

R - Responsible (responsable de la ejecución)

Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe normalmente un rol ITIL responsable de su ejecución.

A - Accountable (responsable del proceso en conjunto)

Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un proceso y que recibe las informaciones de los responsables de la ejecución del proceso.

Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y para cada proceso existe un Responsable de Proceso.

C - Consulted (consultado)

Alguien que no está implicado directamente en la ejecución de un proceso pero que brinda algún tipo de input para el proceso y/o al cual se pide su consejo y opinión.

I - Informed (a informar)

Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del proceso.

Gestor de Incidentes Operaciones IT Infraestructura IT Desarrollo de Sistemas Mesa de Ayuda Soporte VUCE Managment VUCE

Registra incidente Información de Incidente Completa Incidente registrado I R R

Reasigna a nivel 1 Incidente con información faltante Información del incidente verificada R C I

Verifica si es Reclamo o Incidente Información de Incidente Información del incidente verificada R C I Define Prioridad Información de Incidente Completa Información de Incidente Completa

Prioridad definida R C

Actualiza Asunto con la Prioridad Información de Incidente Completa Incidente completo con Prioridad R Comunica Apertura Incidente CRITICO

Información de Incidente Crítico Completo

Comunicación de Apertura Incidente

CRITICO R I I I I

A

Evalua / Analiza Incidente Incidente registrado Incidente analizado R C C

Verifica si es Infraestructura Incidente analizado Incidente analizado R

Abre ticket en ARSAT Incidente analizado Incidente analizado

Ticket de ARSAT R C

Abre Ticket en Jira Modernización Incidente analizado Incidente analizado

Ticket de Jira Modernización R C

Actualiza en el campo solución con el Nro. de Ticket gestionado

Incidente analizado

Ticket de Jira Modernización o ticket de ARSAT

Incidente actualizado R

Actualiza estado a “Espera respuesta” Incidente actualizado Incidente con estado actualizado R Recibe ticket resuelto de ARSAT o Modernización Ticket de ARSAT o Jira de

Modernización resuelto. Incidente actualizado R

Busca Solución en Base de Conocimiento Incidente analizado

Solución existente en Base de Conocimiento o workaround.

Solución NO existente en Base de Conocimiento.

R

Verifica si es Desarrollo Incidente analizado Incidente verificado R

Analiza el Incidente Incidente completo Incidente Analizado C R R

Activa Soporte Incidente analizado Incidente con soporte activado I R

Registra ticket en Jira para Everis Incidente analizado Incidente registrado en Jira Everis I R Actualiza en el campo solución del Incidente el Nro.

de Ticket gestionado

Incidente analizado

Ticket en Jira Everest registrado Incidente actualizado I R R

Actualiza el estado a “Espera respuesta” Incidente analizado Incidente actualizado con estado en

espera I R R

Elabora Solución Incidente analizado

Solución elaborada a implementar (se invoca a subproceso "Resolución de Incidentes")

I R R

Implementa solución Solución a implementar que no

requiere Cambios Acciones de Solución implementadas R IC IC

Valida Incidente Resuelto

Cambios/Requerimientos Gestionados Implementados Acciones de Solución implementadas

Incidente resuelto validado R IC IC C C

Comunica cierre incidente Crítico Incidente resuelto validado Cierre incidente Crítico comunicado I R I I I Documenta la solución y cambia estado a SolucionadoIncidente resuelto validado Registro de Incidente actualizado R C C

Requiere confirmación Mesa de Ayuda Solución de incidente documentada

Solución confirmada con el usuario Efectiva

Solución confirmada con el usuario NO Efectiva

IC R

Cierra Incidente

Solución de incidente documentada Solución confirmada con el usuario (desde el Proceso Gestión de Mesa de Ayuda de VUCE)

Incidente Cerrado I R

TAREAS Entradas Salidas

ROLES Y RESPONSABILIDADES

14

Métricas

La siguiente lista muestra los Indicadores Clave de Rendimiento (KPI / key performance indicators) que deben considerarse para monitorear el desempeño de la Gestión de Incidentes.

KPIs:

➢ Porcentaje de cumplimiento de SLAs

➢ Incidentes pendientes de resolución

➢ Porcentaje de incidentes resueltos dentro de los SLAs por grupo de resolución

➢ Cantidad y porcentaje de incidentes resueltos sin ser derivados a otros grupos de resolución

➢ Cantidad de incidentes registrados por rangos horarios

➢ Porcentaje de incidentes críticos

Reportes:

➢ Disponibilidad del servicio (discriminando entre cortes programados y no programados)

➢ Top 10 de incidentes por categoría

➢ Cantidad de incidentes cerrados y no confirmados por el Usuario

➢ Informe de cierre de incidentes críticos

Normativa Asociada

N/A

ANEXO I

Prioridad de los Incidentes

La prioridad de los incidentes se define en base a la Urgencia y el Impacto.

En la siguiente tabla se establece la prioridad del incidente en función de la urgencia y el impacto.

En la tabla hay cuatro niveles de prioridad, la prioridad 1 es la más crítica del negocio.

Prioridad de un Incidente

IMPACTO

Alto Medio Bajo

URGENCIA

Alta Crítica Alta Media

Media Alta Media Bajo

Baja Media Bajo Bajo

El impacto indica el efecto de un incidente sin resolver en el negocio.

La urgencia se relaciona con la disponibilidad, y mide cuánto tiempo pasará antes de que el incidente tenga un impacto significativo en el negocio, es decir, cuánto tiempo se puede tolerar el incidente sin resolver.

La prioridad se utiliza para determinar el orden en que los incidentes deben ser abordados.

En caso de que múltiples incidentes tengan la misma prioridad, se debe considerar en primera instancia la urgencia y luego el impacto, para identificar la secuencia de trabajo a realizar.

16 Definición de impacto

El impacto se debe evaluar como alto, medio o bajo según los siguientes criterios:

IMPACTO Características

ALTO Impacto mayor en los usuarios. Requiere de una gran cantidad de recursos para su resolución o de la participación de especialistas de distintas áreas.

Existen servicios críticos, de aplicación o infraestructura, con indisponibilidad total. El impacto en el negocio es severo.

Compromisos críticos del negocio no se pueden cumplir (ejemplo, no se puede oficializar una destinación aduanera).

MEDIO Requiere recursos significativos para su resolución, pero podrían existir alternativas de resolución.

Existe una funcionalidad crítica degradada o con lenta respuesta que impacta en el usuario, pero no hay indisponibilidad total. En ciertos casos, debido al horario del suceso su impacto es moderado.

BAJO Su resolución es sencilla y no requiere de gran cantidad de recursos o especialidad técnica.

Sucede sobre un componente no crítico para el usuario o existe una alternativa disponible.

Definición de urgencia

Para evaluar la urgencia se deberán tomar en cuenta los siguientes parámetros:

URGENCIA Características

ALTA Son incidentes que deben ser atendidos inmediatamente, en un plazo máximo de 15 minutos desde que fueron reportados, ya que afectan seriamente la disponibilidad de un servicio crítico.

Es necesario actuar en la resolución de forma rápida.

MEDIA Son incidentes que requieren ser atendidos lo antes posible, en un plazo máximo de una hora desde que son reportados. Se corre el riesgo de impactar más fuertemente al usuario si no se toman acciones.

BAJA Son incidentes que pueden esperar un tiempo razonable por su solución y ser atendidos en más de una hora desde que fueron reportados, en tanto, no se ponga en riesgo la disponibilidad del servicio al usuario.

Nota: los tiempos establecidos para clasificar la urgencia son a modo de referencia y el oferente deberá ajustar sus tiempos para asegurar el cumplimiento de los SLA´s mensuales.

ANEXO II:

Template de comunicaciones de incidentes críticos

APERTURA INCIDENTE PRIORIDAD CRITICA

Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción Se ha abierto un incidente crítico en la plataforma de VUCE.

Servicio/sistema impactado: SERVICIO YYYY Cantidad/tipo de usuarios afectados: NNNN

AVANCE O SEGUIMIENTO INCIDENTE PRIORIDAD CRITICA

Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción

Avance del incidente de VUCE: XXXXXXXXXXXX → indicar las novedades del mismo Servicio/sistema impactado: SERVICIO YYYY

Cantidad/tipo de usuarios afectados: NNNN CIERRE DEL INCIDENTE PRIORIDAD CRITICA

Subject: Incidente Prioridad CRITICA – Número: NNN – Breve descripción Cierre del incidente de VUCE

Servicio/sistema impactado: SERVICIO YYYY Cantidad/tipo de usuarios afectados: NNNN