1

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 Objetivo ......................................................................................................................................... 3

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

3

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

servicio "

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.

5

• 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

7

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.

9

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.

Si no existiera solución ni workaround, continúa con la actividad "Verifica si es Desarrollo".

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

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.

13

Ges

tor

de

Inci

den

tes

Op

erac

ion

es I

T

Infr

aes

tru

ctu

ra

IT

Des

arro

llo d

e

Sist

ema

s

Mes

a d

e A

yud

a

Sop

ort

e V

UC

E

Man

agm

ent

VU

CE

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 CompletaInformación de Incidente Completa

Prioridad definidaR C

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

Comunica Apertura Incidente CRITICOInformación de Incidente Crítico

Completo

Comunicación de Apertura Incidente

CRITICOR 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 analizadoIncidente analizado

Ticket de ARSATR C

Abre Ticket en Jira Modernización Incidente analizadoIncidente analizado

Ticket de Jira ModernizaciónR 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ónTicket 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 RActualiza en el campo solución del Incidente el Nro.

de Ticket gestionado

Incidente analizado

Ticket en Jira Everest registradoIncidente actualizado I R R

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

esperaI 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 ResueltoCambios/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 Solucionado Incidente 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

15

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.

17

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