IN-GTE-02-008 Gestión de Incidentes RV

PROCESO IN-GTE-02-008 HOJA 1
ADMINISTRACIÓN TECNOLÓGICA CODIGO DE 22
INSTRUCTIVO FECHA VERSIÓN

GESTIÓN DE INCIDENTES No. 0
0. CONTROL DE CAMBIOS DOCUMENTAL

VERSION FECHA RAZON DE LA ACTUALIZACIÓN
0 20/Jun/2019 Primera versión
Se incluye en el Literal 7 Políticas y Lineamientos Consideraciones

1
02/Sep/2020 del proceso de Gestión de Incidentes, el registro de Jobs en
Aranda
Se realiza revisión general del proceso y ajustes sobre el mismo, se
2 XXXXX incluyen roles y responsabilidades, Diagrama de flujo del proceso e
indicadores.
1. OBJETO
El objetivo del presente documento es describir las actividades a desarrollar en la gestión de incidentes,
identificando sus principales características y metodología, que conlleve una solución rápida y eficaz de la
restauración del servicio derivado por incidentes que ocasionan una interrupción o degradación del
servicio en el ambiente productivo.
Describir las actividades a desarrollar en la gestión de incidentes, identificando sus principales

características y metodología, brindando una solución rápida y oportuna para la restauración de los
Servicios de TI de la Fiduprevisora S.A en el ambiente productivo, de acuerdo con los ANS establecidos
para la atención de incidentes.
2. ALCANCE
La Gestión de Incidentes cubre las siguientes actividades:

 Manejo de Incidentes:
o Restaurar la operación normal del servicio en el ambiente productivo tan rápido como sea
posible.
o Asignación de un responsable del seguimiento de los incidentes desde su entrada hasta su
resolución.
 Gestión y monitorización continúa de los incidentes durante todo el proceso.
 Identificación de los Incidentes que puedan transformarse en un Problema o en un Incidente
Crítico
o Grave y que desencadene los procesos asociados a éstos.
 Reportes de Gestión: Generar información de gestión sobre la interrupción de los servicios.
 Cumplir los Acuerdos de Nivel de Servicio ANS: Asegurar que los mejores niveles de calidad de
servicio y disponibilidad son mantenidos según los lineamientos definidos en los ANS.
 Soporte a la Operación del Negocio: Minimizar el impacto adverso sobre la operación del negocio.
 Incidentes relacionados a los desarrollos productivos que ya superaron la etapa de estabilización.
 Escalar agestión de problemas los incidentes que reiterativos o los que se considere necesario que
se deben trabajar como problema.

Inicia con el reporte, registro en Aranda y diagnóstico de incidentes en los Servicios productivos de TI de la
Fiduprevisora y termina con la confirmación de la solución por parte del usuario.
3. GLOSARIO
Acuerdos de Niveles de Servicio (SLA/ANS): Es un compromiso que se realiza entre el proveedor de

servicios de Tecnología de la Información TI y un cliente. Un acuerdo de nivel de servicio describe los
objetivos, la lista de servicios de TI, especifica las responsabilidades del proveedor de servicios de TI y el
cliente y establece las métricas de rendimiento. Un acuerdo único puede cubrir múltiples servicios de TI o
varios clientes.
Acuerdo de Nivel de Servicios Operativos (OLA): Es un compromiso entre el proveedor del servicio y otra
parte de la misma organización para brindar el servicio a los usuarios; define las responsabilidades de
ambas partes, así como las métricas para la medición de la prestación del servicio con una calidad
preestablecida. Por ejemplo, podría haber un acuerdo de nivel operativo entre: El proveedor de servicios
de TI y un departamento de compras para adquirir hardware. El Centro de Servicio y un grupo de soporte
para proporcionar la resolución de incidentes en los tiempos acordados.
Aranda: Herramienta de gestión para el registro y seguimiento a las solicitudes (incidentes o

requerimientos) registradas por los usuarios, y que son evaluadas y categorizadas por los Analistas de
Mesa de Servicios.
Base de Datos de Conocimiento (KDB): Es una base de datos lógica que contiene los datos usados por el
Sistema de Gestión del Conocimiento del Servicio.
Base de Datos de Errores Conocidos (BDEC/KEDB): Una base de datos que contiene todos los Registros de
Errores Conocidos. Permite el almacenamiento del conocimiento previo de las incidencias y problemas, y
cómo se superaron, permitiendo agilizar el proceso de diagnóstico y resolución.
Catálogo de Servicios: Es una base de datos o un documento estructurado con información sobre todos
los servicios de TI en producción, incluye aquellos que están disponibles para su implementación. El
Catálogo está conformado por los servicios de cara al cliente que son visibles para el negocio y los de
apoyo.
Cliente: Persona o Empresa que consume bienes o servicios. El cliente de un proveedor de servicios de TI
es la persona o grupo que define y acuerda los objetivos de nivel de servicio. A veces, el término es
utilizado de manera informal para referirse al usuario - por ejemplo, "Esta es una organización centrada
en el cliente”.
CMDB: Base de Datos de la Gestión de la Configuración.
CSI: Mejora Continua del Servicio.
Error Conocido: Problema con la causa raíz conocida para el cual ha sido identificada una solución
temporal o definitiva. Los errores conocidos son creados y gestionados bajo la Gestión de Problemas.

Escalado: Cuando un Analista que recibe una solicitud no la puede solucionar por si solo y requiere la
asistencia de un nivel superior (especialistas o terceros) con mayor conocimiento del tema específico.
Evento de Seguridad de la Información: Según la ISO 27001:2015 se define como presencia identificada
de una condición de un sistema, red o servicio, que indica una posible violación de la política de seguridad
de la información o falla de las salvaguardas, o una situación desconocida previamente que puede ser
pertinente a la seguridad.
Impacto: Medida del efecto de un incidente, problema o cambio en los procesos del negocio. El impacto
está a menudo basado en cómo serán afectados los niveles de servicio.
Incidente: Es una interrupción no planificada de un servicio de TI o la reducción en la calidad de un

servicio de TI. La falla de un elemento de configuración que no ha afectado aún el servicio es también un
incidente.
Incidente Crítico o Grave: Son aquellos incidentes masivos y/o mayores. Un incidente que puede crecer
en el impacto o prioridad para convertirse en un incidente crítico o grave. Estos incidentes, están
asociados a los servicios críticos del negocio y su disponibilidad.
Incidente Masivo: Aquel incidente que cumple con por lo menos una de las siguientes condiciones: afecta
a más de un (1) usuario; afecta todo un sitio, grupo de usuarios, sede, departamento; afecta a toda la
organización.
Incidente Mayor: Incidente registrado en la herramienta de gestión con la categoría de más alto Impacto,
pues tiene como consecuencia una interrupción general del servicio en el negocio; afecta todo un sitio,
grupo de usuarios, sede, departamento o afecta a toda la organización.
Incidente Crítico: Es un incidente priorizado, tiene como consecuencia la interrupción o impacto en un

proceso Core de la organización ejemplo: Pagos, debe ser atendido de manera inmediata.
Incidente de seguridad de la información: Según la norma “ISO 27001:2015” se define como un evento o
una serie de eventos de seguridad de la información indeseados o inesperados, que tienen una
probabilidad significativa de comprometer las operaciones de negocio y de amenazar la seguridad de la
información (Confidencialidad, Integridad y Disponibilidad).
Prioridad: Categoría empleada para identificar la importancia relativa de un incidente, problema o

cambio, está dada entre el impacto y la urgencia.
Problema: Es la causa de uno o más incidentes. Cuando se registra un problema la causa generalmente no
es conocida por lo que la investigación de esta hace parte de la Gestión de Problemas.

Procedimiento: Es una manera específica de realizar una actividad o un proceso. Consiste en seguir pasos
predefinidos para desarrollar una actividad o proceso de manera eficaz.
Proceso: Conjunto estructurado de actividades diseñado para cumplir un objetivo concreto. Un proceso
toma una o más entradas definidas y las transforma en salidas definidas.
Requerimiento: Inclusión, eliminación o modificación de un servicio o componente de un servicio

soportado, planificado o autorizado, y su documentación asociada. p.e. gestión de usuarios, reportes y
consultas, movimientos de equipos.
Servicio: Es un medio de entregar valor a los clientes, al facilitar los resultados que los clientes quieren
lograr sin apropiarse de los costos y riesgos específicos. A veces se utiliza el término “Servicio” como
sinónimo de servicio base, servicio de TI o paquete de servicios.
Solución Temporal (Workaround): Es habitualmente la primera solución que restaura el servicio. No es
una solución permanente, pero hace que el servicio continúe sin sobresaltos.
Soporte Primer Nivel: Es el soporte prestado en línea, telefónicamente o por control remoto, por el
Analista de la Mesa de Servicios. Debe ser brindado por personal con actitud de servicio, capacidad de
trabajo en equipo y habilidad para prestar soporte telefónico.
Soporte Segundo Nivel: Es el servicio prestado en sitio y el soporte técnico prestado por los grupos
resolutores de Soporte (soporte de desarrollo, soporte base de datos, soporte infraestructura,
Proveedores de TI y microinformática). Este equipo está compuesto por ingenieros con actitud de servicio,
capacidad de trabajo en equipo, experiencia y habilidad para desarrollar múltiples tareas.
Soporte Tercer Nivel: Es el que hace referencia al soporte externo, se encontrará sujeto a los acuerdos
vigentes con proveedores de equipos y servicios, con la respectiva supervisión directa del líder de unidad
especializada del segundo nivel.
Servicio de TI: Aplicativos, bases de datos, infraestructura, microinformática, entre otros, prestados por la
Vicepresidencia de Tecnología e información a los usuarios de Fiduprevisora S.A. como medio de entrega
de valor a los usuarios.
Tiempo de Solución: Es el tiempo en el cual se entrega una solución al usuario y/o se le mantiene
informado sobre el estado en la solución de su servicio.
Tiquete o Caso: Es el número de registro asignado por la herramienta de gestión a todas las solicitudes de
servicio realizadas por el usuario. Se tienen en cuenta las solicitudes de información y servicios.
TI: Tecnología de la información.
Urgencia: Es una medida del tiempo en que un incidente, problema o cambio tendrá un impacto
significativo para el negocio.
Usuario: Es la persona que utiliza los servicios de TI en el día a día. Los usuarios son distintos de los
clientes, ya que algunos clientes no utilizan el servicio de TI directamente.
4. RESPONSABLES

Para el Proceso de Gestión de incidentes se tienen los siguientes roles:
Rol Responsabilidad
Gestor de Incidentes del  Asegurar que el personal de soporte tenga los conocimientos necesa-
Outsourcing o fábrica de rios.
Tecnología  Ejecutar del proceso de Gestión de Incidentes.
 Realizar evaluaciones de escalamiento.
 Entender el impacto en el negocio de los incidentes escalados o llama-
das de servicio.
 Asegurar el cumplimiento de los niveles de Servicio establecido en la
resolución de incidentes en su ámbito de responsabilidad.
 Revisar los incidentes que no han sido resueltos a través del proceso es-
tándar de Gestión de Incidentes.
 Gestionar el procedimiento de escalamiento. Detectar posibles proble-
mas y escalamiento de estos a la Gestión de Problemas para la genera-
ción de los registros correspondientes.
 Asegurarla comunicación para un escalamiento planeado y ordenado.
 Usar los resultados de las revisiones post-mortem para determinar las
acciones a seguir.
 Asegurar el cumplimiento de los planes de acción.
 Adelantar revisiones de post-implementación para incidentes mayores
con el fin de generar lecciones aprendidas e identificar oportunidades
de mejora.
 Ser el punto de contacto con los otros Gestores de proceso (problemas,
cambios, configuración) para asegurar su integración y colaboración.
 Elaborar el manejo de los informes y métricas.
 Proveer información de gestión sobre la calidad deservicio y la satisfac-
ción del usuario.
 Gestionar el rendimiento del personal de soporte creando y ejecutando
planes de acción para asegurar la mejora continua.
 Conducir las reuniones de control de estatus de los incidentes de servi-
cio escalados.
 Proveer datos sobre el historial de casos críticos, gestionar los pedidos
de información sobre casos críticos.
Responsable del proceso  Coordinar que el personal de soporte tenga los conocimientos necesa-
de incidentes del Ou- rios.
tsourcing o Fábrica de  Ejecutar el proceso de Gestión de Incidentes.
Tecnología  Asignación de recursos.
 Equilibrar la carga de trabajo entre los equipos de soporte.
 Realizar evaluaciones de escalamiento.
 Entender el impacto en el negocio de los incidentes escalados
o llamadas de servicio.

 Coordinar y supervisar el cumplimiento de los niveles de Servicio exigi-

do en la resolución de incidentes en su ámbito de responsabilidad.
 Gestionar el procedimiento de escalamiento. Detectar posibles proble-
mas y escalamiento de estos a la Gestión de Problemas para la genera-
ción de los registros correspondientes.
 Coordinar la comunicación para un escalamiento planeado y ordenado.
 Coordinar la creación de los equipos de escalamiento.
 Usar los resultados de las revisiones post-mortem para determinar las
acciones a seguir.
 Desarrollar, documentar y monitorear los planes de acción.
 Adelantar revisiones de post-implementación para incidentes mayores
con el fin de generar lecciones aprendidas e identificar oportunidades
de mejora.
 Ser el punto de contacto con los otros Gestores de proceso
 (problemas, cambios, configuración) para asegurar su integración y co-
laboración.
 Elaborar el manejo de los informes y métricas
 Proveer datos sobre el historial de casos críticos, gestionar los pedidos
de información sobre casos críticos.
Soporte Primer Nivel  Recibir y atender llamadas del usuario
 Registrar incidencias del servicio
 Verificar que los incidentes estén cubiertos por los ANS’s
 Actualizar el registro de incidentes en el sistema de gestión de inciden-
tes.
 Categorizar y priorizar incidentes de servicio.
 Entender los niveles de servicio y ejecutar sus tareas alineándose a
ellos.
 Consultar base de datos de errores conocidos, con el fin de ver si hay al-
guna solución que sea aplicable.
 Usar los recursos disponibles para resolver incidentes (personas, proce-
sos y herramientas). Resolver consultas en su nivel de conocimiento.
 Realizar un primer nivel de soporte que consiste en comprobar si pue-
den resolver el incidente utilizando sus instrucciones de actuación. Esta
resolución se produce en incidencias cuya solución está documentada y
es conocida, rápida y aplicable por este nivel de soporte.
 Realizar escalamiento de incidentes a un segundo nivel de soporte.
 Informar al usuario sobre el progreso del incidente
 Proveer comunicación técnica al usuario
 Una vez resuelto el incidente, cerrar el mismo siguiendo los procedi-
mientos aplicables y con la autorización del usuario.
 Asegurar que el usuario acuerde que la solución dada resolvió sus nece-
sidades antes del cierre del incidente de servicio.
 Proveer información detallada y acertada a la gerencia sobre la calidad

del soporte.
 Gestionar las reaperturas y reclamaciones de incidencias.
Soporte Segundo Nivel  Resolución de incidentes.
 Entender los niveles de servicio y ejecutar sus tareas alineándose a
ellos.
 Consultar base de datos de errores conocidos, con el fin de ver si hay al-
guna solución que sea aplicable.
 Iniciar los procedimientos de escalado de incidencias a los niveles de
autoridad que deban intervenir en la supervisión del tratamiento.
 Identificar, propone y aplica soluciones para la rápida restauración del
servicio al usuario.
 Documentar en el registro la solución aplicada (detalle de las transac-
ciones realizadas en el tratamiento del mismo) y el resultado obtenido.
 Dar “una respuesta” sobre la incidencia que le haya sido asignada o es-
calada.
 Usar los recursos disponibles para resolver incidentes (personas, proce-
sos y herramientas).
Soporte Tercer Nivel  Puede enfocarse en los problemas complejos relacionados con aspectos
operativos que no han podido ser resueltos por el primer o segundo ni-
vel de soporte.
 Proveer conocimiento y entrenamiento a los niveles inferiores de so-
porte.
 Formar parte de los equipos de resolución para incidentes escalados.
 Detectar posibles problemas e informar al Gestor de Incidentes (notifi-
cación al Gestor de Problemas).
 Si fuera requerido, interactúa con proveedores externos para la resolu-
ción de los incidentes.
 Definir políticas y estándares para operar el proceso de Gestión de Inci-

dentes.
 Participar en el diseño del proceso y los cambios del mismo.
 Asegurar el patrocinio, diseño y gestión de cambios del proceso y sus
Dueño del proceso Ges-
métricas.
tión de Incidentes
 Velar por que el proceso de Gestión de incidentes este ajustado a su
propósito y asegurar que las actividades dentro del proceso se realicen.
 Revisar periódicamente la estrategia del proceso para asegurar su con-
formidad y proponer cambios si es necesario.
 Manejar la eficiencia y efectividad del proceso de la Gestión de inciden-
tes.
 Asegurar que todas las actividades son llevadas a cabo como se requie-
re a través del ciclo de vida del servicio.
Gestor de Incidentes
 Comunicar y divulgar la información del proceso y los cambios al mismo
para asegurar el conocimiento, entendimiento e implementación.
 Monitorear la efectividad de la Gestión de incidentes y realizar reco-
mendaciones de mejora.

 Coordinar interfaces entre la gestión de incidentes y otros procesos de

gestión de servicios de TI que se encuentren implementados.
 Generar las métricas e indicadores del proceso para su evaluación y ha-
cer recomendaciones para la mejora.
 Apoyar a los analistas y especialistas de Mesa de Servicios en los escala-
mientos tanto funcionales como Jerárquicos.
 Gestionar el esquema de comunicación de los incidentes mayores.
 Reportar los incidentes a la Mesa Servicios a través de los canales esta-
blecidos.
 Contactar a la mesa de servicios de TI a través de los canales estableci-
dos para realizar el reporte de incidentes de servicios de TI.
 Brindar la información completa y veraz para la oportuna atención de
los incidentes.
 Atender el llamado de la Mesa de Servicios o del personal técnico de TI
Usuario
en caso de requerir validaciones o conexión remota.
 Verificar que la solución brindada por la mesa de servicio/Grupo resolu-
tor, cumpla con lo requerido.
 Aprobar el cierre de los incidentes realizados vía telefónica.
 Calificar el servicio a través de la encuesta de satisfacción generada.
 Atender de manera cordial al usuario y mantener el protocolo de aten-
ción del modelo de calidad de la organización.
 Registrar los incidentes recibidos vía telefónica (para casos donde el
usuario no pueda registrar el incidente en Aranda).
 Analizar los incidentes de servicio para una correcta tipificación, catego-
rización y priorización.
Analista de Mesa de Ser-  Diagnosticar y solucionar los incidentes que estén dentro del alcance de-
vicio finido para primer nivel, de lo contrario escalar a segundo nivel (especia-
lista) dentro de los tiempos establecidos en los acuerdos.
 Priorizar el incidente de acuerdo al impacto y urgencia.
 Documentar y actualizar el incidente para que el usuario se mantenga
informado.
 Realizar análisis, diagnóstico técnico y resolver los Incidentes dentro del
alcance definido para el nivel 1.5, dentro de los tiempos comprometidos
en los acuerdos de niveles de servicio, de lo contrario escalar a segundo
nivel (Especialista).
Especialista Mesa de Ser-  Participar en la mejora continua del proceso.
vicios  Participar en la gestión de alimentación de la base de datos de conoci-
miento.
informado.
 Realizar análisis, diagnóstico técnico y resolver los Incidentes dentro de

Especialistas Segundo Ni- los tiempos comprometidos en los acuerdos de niveles de servicio.
vel  Proporcionar comunicación técnica, manual e instructiva al grupo de es-
pecialistas de Mesa de servicios para mejorar y agilizar la solución de in-

cidentes.

Gestionar el incidente ante el proveedor o fabricante correspondiente
en caso de ser necesario y actualizar estado en la herramienta de ges-
tión.
informado.
 Monitorear el estado y el progreso de la solución de los incidentes de
servicio asignados.
 Mejorar los tiempos de solución de incidentes y la calidad de la informa-
ción.
 Participar en la mejora continua del proceso.
 Participar en la gestión de alimentación de la base de datos de conoci-
miento.
 Dar trámite y solución a los incidentes mayores
 Realizar análisis, diagnóstico técnico especializado y resolver los Inciden-
tes dentro de los tiempos comprometidos en los acuerdos de niveles de
servicio.
Proveedor
 Proporcionar soluciones temporales o definitivas sobre los incidentes
escalados.
 Informar o reportar el avance del caso.
5. DOCUMENTOS RELACIONADOS
 ML-GTE-02-001 Política de Gestión Tecnológica

 MP-GTE-02-009 Función Mesa de Servicios
 IN-GTE-02-006 Acuerdos de Servicios Tecnológicos
 IN-GTE-02-009 Gestión de Requerimientos
 IN-GTE-02-011 Gestión de Cambios
 IN-GTE-02-016 Gestión de Problemas
 FR-GTE-02-029 Matriz Impacto Prioridad Urgencia
 IN-GTE-02-014 Gestión del Catálogo de Servicios
 MP-ESC-05-003 Gestión de Incidentes de Seguridad de la Información
 Anexo Matriz de personas autorizadas
 Base de datos de errores conocidos (KEDB) – En Aranda
7. POLITICAS Y LINEAMIENTOS
a. FUERA DEL ALCANCE
Los elementos que no hacen parte del alcance del proceso de Gestión de Incidentes:
 Monitoreo de eventos
 Gestión de los Requerimientos de Servicio.
 Solicitud para un servicio nuevo o adicional
 Incluir siempre análisis de causa/raíz (Gestión de Problemas)
 Incluir siempre una solución permanente/estructural. Una solución alterna es suficiente.

 Los incidentes no hacen parte del desarrollo e implementación de nuevas funcionalidades, dado a que
son mantenimientos correctivos y no como están catalogados los demás mantenimientos (Perfectivo,
Adaptativo, Evolutivo o Nuevas Mejoras) Ver Metodología de Desarrollo V1.0
 Los incidentes asociados a los ambientes de pruebas y desarrollo serán registrados en la herramienta de
gestión de incidencias en pruebas para su seguimiento; los cuales no serán contemplados en el proceso de
gestión de Niveles de Servicio (Medición ANS).
b. CONCEPTOS BÁSICOS
El proceso de gestión de incidentes está enfocado en restaurar los servicios de tecnología gestionando los
incidentes que ocurren en la infraestructura, aplicaciones o que son reportados por los usuarios para los
ambientes productivos. Este proceso busca minimizar el impacto y la interrupción de los servicios
soportados de acuerdo con el Catálogo de Servicios. La Gestión de Incidentes tiene como objetivo
principal la restauración de los servicios de producción tan rápido como sea posible ya sea mediante una
solución temporal o definitiva.
Los incidentes que no puedan ser resueltos inmediatamente por la Mesa de Servicios (Soporte de primer
nivel), deben ser asignados a grupos especialistas o soporte de segundo nivel. Una solución definitiva o
solución alterna debe ser realizada tan rápido como sea posible para restaurar el servicio de producción a
los usuarios con la mínima interrupción a su trabajo. Después de solucionar el incidente y la restauración
del servicio, el incidente es cerrado.
La Mesa de Servicios actúa como único punto de contacto con el usuario y debe suministrar información
de las solicitudes registradas por los mismos (avance, estado, progreso, solución), es importante que el
registro del incidente sea asegurado a través del ciclo de vida de este y el historial de los procesos
realizados será mantenido para realizar las investigaciones necesarias una vez sea resuelto el incidente.
c. CONSIDERACIONES DEL PROCESO DE GESTIÓN DE INCIDENTES
En la solución de los incidentes reportados por los usuarios, el especialista debe indicar la causa que
generó la inconsistencia e indicar la solución que se le brindó a la misma. Las descripciones de los
incidentes generados por el usuario deben ser claras y contener la información mínima para que el
especialista pueda brindar solución a su solicitud.
Esto indica:
1. Descripción clara de la incidencia presentada
2. Aplicación o Base de Datos que se ve afectada (FOMAG1- PEOPLESOFT - PORFIN – etc.)
3. Pantallazo como evidencia de la misma. 4. Fallos de ejecución de los Jobs programados.
En dado caso que el alcance de la solicitud sea diferente a lo requerido por el usuario inicialmente, se
procederá a informar al usuario la atención realizada de la solicitud y la necesidad de realizar una nueva
creando un nuevo tiquete o caso. De igual manera, se procederá cerrar inmediatamente el caso.
Toda solicitud en la cual sea requerida información adicional del usuario, se le informará para que ésta sea
entregada. En estos casos se realizará 1 notificación con la solicitud de aclaración o información con un

tiempo máximo de espera de 2 días hábiles, con lo cual se realiza un cambio ha estado “Pendiente por el
Cliente”. De no recibir información alguna por parte del usuario en 10 horas hábiles, ésta será cambiada
de estado a Resuelto en la herramienta Aranda, en donde se informará el motivo del cambio de estado.
Toda solicitud en la cual sea necesaria aprobación, validación o información por parte de la Gerencia de
Tecnología, se cambiará su estado a “Pendiente por Autorización” y será reasignada. Una vez se cuente
con la aprobación y/o información por parte de la Gerencia de Tecnología, ésta se reasignará nuevamente
al especialista que lo ha solicitado cambiando su estado a “Abierto”.
Si la Gerencia de Tecnología al validar los incidentes reportados, evidencia que el incidente se encuentra
en estado “Pendiente por el Cliente”, Pendiente de Autorización” o “Pendiente por Proveedor” y no está
debidamente justificado en la herramienta Aranda no cumple con los tiempos de excepción establecidos
en el Proceso de Tiempos de Excepción, se cambiará el estado a “Abierto”, informando a la Mesa de
Servicio el motivo por el cual se cambia el estado. La Mesa de Servicio informa al especialista del cambio
de estado para su validación y solución del incidente.
d. TRATAMIENTO DE INCIDENTES DE SEGURIDAD
Tomando como base la norma ISO 27001:2015 incidente de seguridad de la información se define como
un acceso, intento de acceso, uso, divulgación, modificación o destrucción no autorizada de información;
un impedimento en la operación normal de las redes, sistemas o recursos informáticos; o una violación a
la Política de Seguridad de la Información de la organización. Para que un evento se catalogue como
incidente de seguridad de la información debe existir una probabilidad real de compromiso de la
operación del negocio a causa de la afectación de cualquiera de las propiedades de la seguridad de la
información “Confidencialidad, Integridad y Disponibilidad”. Algunos escenarios donde se materializaría
una probabilidad real de compromiso de la operación del negocio:
 Compromiso de la red.
 Denegación de servicio.
 Compromiso de la operación de una aplicación.
 Compromiso del Firewall.
 Compromiso de un servidor.
Los incidentes de seguridad que se presenten de acuerdo con lo anteriormente descrito deberán
atenderse de manera inmediata y en un tiempo no mayor a 24 horas corridas (7x24). En cuanto a la
probabilidad de amenaza de cualquiera de las propiedades de la seguridad de la información
“Confidencialidad, Integridad y Disponibilidad” se debe tramitar ante la Gestión de Eventos la amenaza de
dichas propiedades que implican el compromiso de la operación del negocio y los cuales deben ser
tratados como evento de seguridad de la información sin desconocer que se debe dar premura a su
tratamiento, el cual debe registrase y categorizarse como un requerimiento de tarea programada en la
herramienta de Gestión de Incidentes para su respectivo proceso de investigación.

6. DESARROLLO DEL PROCESO


6.1 DIAGRAMA DE FLUJO


6.2 DESCRIPCION DE ACTIVIDADES
ROL RESPONSABLE PRODUCTO/SISTEMAS DE

ACTIVIDAD
INFORMACIÓN/PERMISOS
Usuario
1. Reportar Incidente
Reportar el incidente e informarlo a la Mesa de Servicios mediante el PRO: Incidente Reportado
módulo de autoservicio de Aranda establecido para ello o marcando a la SIS: Aranda
extensión definida en el Proceso Función Mesa de Servicio. PER: N/A
Usuario 2. Registrar y clasificar

(Herramienta de Registrar el incidente con los datos requeridos para su respectiva
gestión:
Gestión) y - Descripción clara de la incidencia presentada
Analista Mesa - Aplicación o Base de Datos que se ve afectada (FOMAG1-
de Servicios PEOPLESOFT - PORFIN – etc.)
- Pantallazo como evidencia de la misma.
- Fallos de ejecución de los Jobs programados.
El analista de Mesa de Servicios valida si el registro quedó bien PRO: Caso Registrado en la
clasificado de acuerdo con las siguientes condiciones: herramienta de Gestión.
- Tener claridad del servicio afectado que este dentro del catálogo de SIS: Aranda
servicios. PER: N/A
- Que exista interrupción no planeada de un servicio o degradación del
mismo.
- Que no se trate de una solicitud especifica de un servicio.
¿Es un incidente?
Si: Continuar con la actividad No 3
No: inicia procedimiento de requerimientos según el documento IN-
GTE-02-009 Gestión de Requerimientos
Fin del Procedimiento
Analista Mesa 3. Categorizar y Priorizar
de Servicios Categorizar y priorizar el incidente a partir de las siguientes condiciones:
- Según el incidente reportado asociar la categoría de acuerdo a lo
establecido en el documento “Catálogo de servicio”.
- Consultar modelo de incidentes definido
- Priorizar el incidente según el impacto y la urgencia dados en el FR-
GTE-02-029 Matriz Impacto Prioridad Urgencia. PRO: Incidente
categorizado y priorizado.
¿Es un incidente Mayor? SIS: Aranda
Validar si es un único usuario afectado o si existen más usuarios PER: N/A
afectados.
- En el caso de afectación masiva de usuarios, comunicar la novedad al
Gestor de incidentes (Coordinador de Mesa).
Si: Iniciar Procedimiento Incidentes Mayores.
No: Continuar con la actividad No 4.
Analista Mesa 4. Diagnosticar y Solucionar PRO: Diagnóstico inicial

de Servicios Realizar el diagnóstico inicial a partir del siguiente análisis: del incidente – Solución
- Indagar sobre el inconveniente presentado con el usuario. del incidente
- Consultar la base de datos de conocimiento (KDB), en caso de ser un SIS: Aranda


ACTIVIDAD
error conocido.
¿Incidente Resuelto?
PER: N/A
No: ¿Se debe escalar con Especialista de Mesa?
No: Continuar con la actividad No 7
Analista Mesa 5. Validar y Documentar Solución

de Servicios – Validar con el usuario si la solución es exitosa. Luego de la validación se
describe de forma detallada la solución brindada al usuario bajo las PRO: Incidente
Especialista de siguientes condiciones: Solucionado
Mesa- - Causa del incidente SIS: Aranda
Especialistas - Solución aplicada PER: N/A
Segundo Nivel
Continuar con la actividad No 11
Especialista de 6. Diagnosticar y solucionar
Mesa - Realizar diagnóstico del incidente.
- Consultar en la Base de conocimiento (KDB), en caso de ser un error
PRO: Diagnóstico inicial
conocido.
del incidente – Solución
- Aplicar check list y procedimientos de solución.
del incidente
SIS: Aranda
¿Incidente Resuelto?
PER: N/A
No: Continuar con la actividad No 7
Analista Mesa 7. Escalar a especialista

PRO: Diagnóstico del
de Servicios – Escalar a especialista documentando las siguientes características:
incidente – Solución del
- Diagnóstico inicial
Especialista de - Usuario (s) afectado (s)
incidente
Mesa SIS: Aranda
- Descripción del error y pantallazo del error (si se requiere)
PER: N/A
Continuar con la actividad No 8.
Especialistas 8. Diagnosticar y Solucionar
Segundo Nivel Diagnosticar el incidente.
Consultar la base de datos de conocimiento (KDB), en caso de que sea
un error conocido.
El especialista VTI valida:
¿Es un incidente de Seguridad? PRO: Diagnóstico del
Si: Notifica al proceso MP-ESC-05-003 Gestión de Incidentes de incidente – Solución del
Seguridad de la Información mediante el incidente
registro de un caso en la opción de Aranda 4. Seguridad de la SIS: Aranda
información. PER: N/A
Continua con las actividades para solucionar el incidente.
No: ¿Incidente Resuelto?
Si: continua con la actividad No 5.
No: Continuar con Actividad No 9.
Especialistas 9. Escalar con el proveedor PRO: Incidente Escalado a

Segundo Ejecutar las acciones necesarias para escalar con el proveedor y que den Proveedor
solución al incidente. SIS: Aranda
Nivel Continuar con la actividad 10. PER: N/A


ACTIVIDAD
Especialistas 10. Validar solución Proveedor PRO: Incidente
Segundo Nivel – Realizar seguimiento con el proveedor hasta que se brinde solución al Solucionado
incidente. SIS: Aranda
Proveedor Continuar con la actividad 5. PER: N/A
Usuario 11. Confirmar Solución
para realizar el cierre del incidente el usuario diligencia la encuesta de
satisfacción que está definida en la herramienta de Gestión de
PRO: Incidente Cerrado
Incidentes.
SIS: Aranda
¿Está conforme con la solución dada?
PER: N/A
Si: se genera cierre automático del incidente.
Fin del Procedimiento
No: Se reabre el caso y Continuar con la actividad No 4
6. DESARROLLO
1. Detección de Incidentes
Cualquier usuario de la organización puede detectar un incidente e informarlo a la Mesa de Servicios
mediante el módulo de autoservicio establecido para ello o marcando a la extensión 5555. (Ver Proceso
Función Mesa de Servicio).
Se debe tener en cuenta que la solicitud de atención de un incidente es realizada sólo por el personal
autorizado para ello (ver Matriz de Personas Autorizadas FIDUPREVISORA S.A.).
2. Validación de solicitud
Las actividades en este flujo de trabajo están enfocadas en asegurar que todos los incidentes
reportados sean correctamente registrados y validados.
Después de la recepción de un incidente, el Analista de Soporte de Primer Nivel ingresa en su pantalla

de Aranda para asegurar su validez y completitud e incluir cualquier información adicional que pueda
ser requerida.
¿El reporte cuenta con la información completa?
Si: Ir a la actividad Nº4
No: Ir a la actividad Nº3.
3. Categorización y Cierre
Se cierra el incidente reportado indicando en los comentarios de cierre el motivo del mismo y los datos
que no fueron incluidos por el usuario solicitando un nuevo registro con toda la información requerida.
Fin del procedimiento.
4. Categorización
Una vez validado el incidente reportado por el usuario, el Analista de Soporte de Primer Nivel realiza
la clasificación del incidente en la herramienta Aranda documentando el tipo de solicitud, de acuerdo
con la Matriz de servicios definida en el instructivo de gestión del Catálogo de Servicios IN-GTE-02-014.
5. Tratamiento de la solicitud

Una de las variables más importantes de este tipo de solicitudes es la prioridad de la falla, lo que,
determina el orden para su atención.
La mejor práctica para determinar la prioridad es a través de la definición del impacto y la urgencia; en
términos más sencillos: PRIORIDAD = IMPACTO x URGENCIA. Por esta razón se presentan estos tres
elementos juntos, puesto que su utilización está intrínsecamente relacionada.
Cuando el incidente es recibido por la Mesa de Servicios, éste debe seleccionar el Impacto que tiene el
incidente.
Los incidentes registrados que no se resuelven en primer nivel, se escalan a soporte de Segundo Nivel
(Coordinador Outsourcing o Fábrica) quien se encargará de delegar a los especialistas de acuerdo con
su experticia.
Frente a la prioridad, se deben identificar los siguientes conceptos:
 Tiempo de Respuesta: por respuesta se entiende, recibir la asignación de la falla y mandar una
notificación al usuario.
 Tiempo de Solución: no incluye el tiempo de observación o confirmación de la solución.
De acuerdo con los valores de la FR-GTE-02-029 Matriz Impacto Prioridad Urgencia.
6. Diagnóstico inicial
El soporte de Primer Nivel valida la información suministrada en el incidente.

¿El incidente puede ser resuelto por el nivel de soporte actual?
Si: Ir a la actividad Nº 8.
No: Ir a la actividad Nº 7
7. Escalar el incidente
Se asigna el tiquete al especialista de soporte a fin de continuar con la solución del incidente
documentando todos los pasos previos realizados en primer nivel.
8. Investigación y diagnóstico
Cuando se gestiona un incidente, cada grupo de soporte investiga qué es lo que ha fallado y realiza un
diagnóstico. Todas estas actividades deben quedar registradas en la herramienta de Gestión para que
así el soporte de Primer Nivel pueda informar al usuario la actualización del incidente, si éste así lo
requiere.
Dentro de las validaciones realizadas, se verifica si la incidencia reportada corresponde a un incidente
reiterativo.
¿Es un incidente reiterativo?
Si: Escalar el tiquete para tratarlo dentro de la Gestión de Problemas. Fin del procedimiento.
No: Ir a la actividad Nº 9).
9. Solución y recuperación
Si se ha determinado una posible solución, lo siguiente que hay que hacer es implementarla y probarla.
Realizar pruebas unitarias comprobando el correcto funcionamiento de la solución de la incidencia y
dejando evidencia de esta prueba en Aranda.
El grupo de soporte documenta el diagnóstico encontrado y la solución en la herramienta de gestión
obligatoriamente y asignará el estado del caso como Resuelto a fin de que el usuario sea notificado por

la herramienta.
En caso de requerir información adicional o apoyo de otras líneas de servicio, el analista de Mesa de
Servicios o especialista deberá realizar cambio de estado de la solicitud en la herramienta de gestión,
de tal manera que se mantenga la trazabilidad del caso y se manejen apropiadamente los tiempos de
los ANS establecidos.
Los estados (tiempo de excepción) que podrá utilizar son:

Pendiente por Autorización: Tiempo utilizado en las autorizaciones por parte de la Gerencia
de Tecnología.
- Pendiente por el Usuario: Tiempo utilizado en información complementaria por parte del
usuario o pruebas de usuario.
- Pendiente por el Proveedor: Tiempo utilizado mientras el proveedor da respuesta.
- Resuelto: Tiempo utilizado para que el usuario valide la solución y se de cierre al tiquete
(automático o por solicitud del usuario)
NOTA: Quien se encuentre dando tratamiento a la solicitud no podrá cerrarla en la herramienta, sin
antes pasar por el estado resuelto.
10. Validar Solución de Tercer Nivel

Cuando la solución la realiza el soporte de tercer Nivel, éste indica la solución al soporte de segundo
Nivel para que puedan ejecutar o verificar la solución que se implementó para el incidente.
11. Primera y Segunda notificación de la solución de solución

Primera y Segunda notificación de la solución de solución
Una vez solucionada la solicitud se realizan dos (2) notificaciones al usuario para dar trámite de cierre
a la misma, la primera cuando el servicio está resuelto o se considera atendido y se informa de este
estado esperando confirmación del usuario y una segunda notificación en caso de no haber recibido
respuesta del usuario.
¿El usuario se encuentra de acuerdo con la solución brindada?
Si: Ir a la actividad Nº 12.
No: Si el usuario no se encuentra de acuerdo con la solución brindada, éste remitirá su inconformidad
a la Mesa de Servicios a través del correo electrónico mesadeservicios@fiduprevisora.com.co Se
devuelve a la actividad N°6, con el fin de revisar y validar las observaciones del usuario.
12. Cierre de incidente

Cuando el usuario aprueba el cierre de la solicitud el Analista de Mesa de Servicios procede al cierre
de la solicitud a través de la herramienta.
Para el Cierre del Tiquete la herramienta envía automáticamente tres (3) notificaciones al usuario final
en un lapso de 10 horas hábiles cada una. Si el usuario en las dos primeras notificaciones no ha dado
respuesta, en la tercera notificación que se envíe al usuario, se le informará que el tiquete se dará por
cerrado y aceptada la solución en un tiempo determinado.
Fin del procedimiento
7. POLÍTICAS Y LINEAMIENTO

- La Gestión de incidentes debe garantizar el registro de un caso para la atención de cualquier

incidencia.
- Garantizar que todos los incidentes reportados por los usuarios de la Fiduprevisora tengan un
caso registrado en la herramienta.
- La Gestión de incidentes debe asegurar el correcto escalamiento tanto funcional como jerár-
quico, el incidente debe tener una solución temporal o definitiva tan rápido como sea posible
para restaurar el servicio a los usuarios.
- El especialista de TI debe indicar en la solución del incidente la causa que lo generó e indicar
la solución brindada.
- Los analistas de Mesa de servicios y especialistas pueden hacer re-categorización de los
incidentes en la herramienta de gestión en caso de que se identifique que el diagnóstico sobre
la falla modifica la clasificación del Incidente.
- Si se presentan Incidentes duplicados (más de un incidente para la misma falla o CI), el
Incidente más reciente se debe cerrar y se debe asociar la interacción al Incidente más
antiguo.
- La prioridad crítica de los incidentes solo puede ser asignada por el Gestor de Incidentes.
- Todo incidente para poder ser cerrado debe generar encuesta de satisfacción al usuario.
- Todas las interacciones con los usuarios deben quedar registradas en el historial del caso en la
herramienta de Gestión.
- Los incidentes que se presenten por periodo de estabilización de las aplicaciones serán
descritos como tal por el usuario para que sean soportados por el grupo de tercer nivel de
acuerdo con el desarrollo realizado. Estos incidentes no se contemplan dentro de la Medición
de ANS. El proceso de atención de estas solicitudes se enmarca en el Manual de Mesa de
Servicios.
- Los incidentes que se diagnostiquen como incidentes de seguridad, deberán atenderse de ma -
nera inmediata y se deberá informar al área de seguridad de la información con el registro de
un caso según lo establecido en el documento MP-ESC-05-003 Gestión de Incidentes de Segu -
ridad de la Información e informar al Líder se seguridad informática.
- La gestión de incidentes debe escalar al proceso de Gestión de problemas los incidentes reite -
rativos o los que se considere necesario que se deben trabajar como problema.
9. RELACIÓN CON OTROS PROCESOS DE TI
Procesos/Funciones Relación
La gestión de incidentes detecta eventualmente posi-
bles problemas que escala al gestor de dicho proceso.
Gestión de problemas De igual forma, se apoya en la base de datos de
errores conocidos para resolver ítems de servicio.

Procesos/Funciones Relación
Proporciona los datos que se utilizan para identificar
y controlar incidencias. El Sistema de Gestión de la
Configuración (CMS) se usa, entre otras cosas, para
identificar componentes defectuosos y determinar el
Gestión de la configuración
impacto de una incidencia. La gestión de incidentes
informa a la gestión de la configuración acerca de
aquellos elementos (CI) afectados con el incidente,
para que sean actualizados en la CMDB.
Si se necesita un cambio para implementar una solu-
ción permanente o provisional, se emite una solicitud
de cambio y se traslada a la Gestión de Cambios. La
Gestión de Cambios
Gestión de Incidentes también puede controlar y so-
lucionar incidencias debidas a cambios improceden-
tes.
La Gestión de Incidentes inicia la monitorización del
rendimiento si se produce algún problema de rendi-
Gestión de la Capacidad
miento. La Gestión de la Capacidad puede proponer
soluciones provisionales para resolver incidentes.
La Gestión de la Disponibilidad emplea datos de la
Gestión de Incidentes para determinar la disponibili-
Gestión de la Disponibilidad
dad de servicios de TI y detectar dónde se puede me-
jorar el Ciclo de Vida de una incidencia.
La gestión de incidentes debe tener acceso a los ANS
Gestión de Niveles de Servicio acordados con el FIDUPREVISORA S.A. S.A. para poder
determinar el curso de las acciones a adoptar.
Ambos procesos se retroalimentan de manera perma-
nente, para permitir que errores conocidos, pregun-
Gestión del Conocimiento tas y respuestas y otros temas de conocimiento de la
operación esté almacenados y publicados en la Base
de datos de conocimiento.
La mesa de servicios es el único punto de contacto
para el registro de incidentes de la operación y el ca-
Función de Mesa de Servicios
nal de comunicación entre los soportes de segundo y
tercer nivel con el usuario final.
f. INDICADORES
- Porcentaje de incidentes resueltos durante el tiempo acordado en el ANS
- Número de incidentes críticos resueltos y pendientes.
8. INDICADORES

NOMBRE DESCRIPCIÓN / FÓRMULA META PERIODICIDAD

PCANS: (CIANS/CISM)*100
PCANS= Porcentaje de cumplimiento de
Porcentaje de ANS de incidentes.
CIANS= Cantidad de incidentes que
cumplimiento de ANS de ≥ 95% Mensual
cumplieron con la solución en el tiempo
incidentes
estipulado en el ANS.
CISM = Cantidad de Incidentes Registrados
en la herramienta de Gestión
Porcentaje de satisfacción PSU=(PUS/TED) *100

de usuarios en Incidentes PUS=Porcentaje de usuarios satisfechos ≥ 80% Mensual
(PSU) TED=Total de encuestas diligenciadas
IR: (CIR/CISM) *100

IR = Porcentaje de Incidentes Reabiertos
Porcentaje de Incidentes CIR = Cantidad de Incidentes Reabiertos <= 10 % Mensual
Reabiertos (IR) CISM = Cantidad de Incidentes Registrados
Promedio de tiempo PT: (TTI/CISM) 8 horas Mensual
transcurrido para la
PT= Promedio de tiempo Solución
solución de Incidentes
TTI= Total de tiempo de incidentes
CISM = Cantidad de Incidentes Registrados
g. REGISTROS
a. REGISTROS
No. ACTIVIDAD NOMBRE DEL REGISTRO RESPONSABLE SOPORTE/ FORMATO

1. Registro de Incidentes Número de Incidente Analista Mesa de Herramienta
Servicios Aranda Tiquete/caso
b. ANEXOS
Matriz Impacto Prioridad Urgencia v1.0


FIRMA _______________________________________ FIRMA _______________________________________

NOMBRE MYRIAM LUCIA SANTAMARIA NOMBRE MARIO ANDRES PIRACHICAN GIL
FECHA FECHA
ELABORÓ REVISÓ
LIDER DE PROCESOS ITIL LIDER DE SERVICIOS DE TI
FIRMA _______________________________________
NOMBRE WILSON CAMARGO
FECHA
APROBÓ
VICEPRESIDENTE DE TECNOLOGÍA E INFORMACIÓN

IN-GTE-02-008 Gestión de Incidentes RV

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

IN-GTE-02-008 Gestión de Incidentes RV

Cargado por

Copyright:

Formatos disponibles

PROCESO IN-GTE-02-008 HOJA 1

ADMINISTRACIÓN TECNOLÓGICA CODIGO DE 22

INSTRUCTIVO FECHA VERSIÓN

0. CONTROL DE CAMBIOS DOCUMENTAL

0 20/Jun/2019 Primera versión

Se incluye en el Literal 7 Políticas y Lineamientos Consideraciones

Describir las actividades a desarrollar en la gestión de incidentes, identificando sus principales

La Gestión de Incidentes cubre las siguientes actividades:

INSTRUCTIVO FECHA VERSIÓN

Acuerdos de Niveles de Servicio (SLA/ANS): Es un compromiso que se realiza entre el proveedor de

Aranda: Herramienta de gestión para el registro y seguimiento a las solicitudes (incidentes o

CMDB: Base de Datos de la Gestión de la Configuración.

CSI: Mejora Continua del Servicio.

INSTRUCTIVO FECHA VERSIÓN

Incidente: Es una interrupción no planificada de un servicio de TI o la reducción en la calidad de un

Incidente Crítico: Es un incidente priorizado, tiene como consecuencia la interrupción o impacto en un

Prioridad: Categoría empleada para identificar la importancia relativa de un incidente, problema o

INSTRUCTIVO FECHA VERSIÓN

Requerimiento: Inclusión, eliminación o modificación de un servicio o componente de un servicio

TI: Tecnología de la información.

INSTRUCTIVO FECHA VERSIÓN

Para el Proceso de Gestión de incidentes se tienen los siguientes roles:

INSTRUCTIVO FECHA VERSIÓN

 Coordinar y supervisar el cumplimiento de los niveles de Servicio exigi-

INSTRUCTIVO FECHA VERSIÓN

 Definir políticas y estándares para operar el proceso de Gestión de Inci-

INSTRUCTIVO FECHA VERSIÓN

 Coordinar interfaces entre la gestión de incidentes y otros procesos de

 Realizar análisis, diagnóstico técnico y resolver los Incidentes dentro de

INSTRUCTIVO FECHA VERSIÓN

 ML-GTE-02-001 Política de Gestión Tecnológica

INSTRUCTIVO FECHA VERSIÓN

c. CONSIDERACIONES DEL PROCESO DE GESTIÓN DE INCIDENTES

INSTRUCTIVO FECHA VERSIÓN

d. TRATAMIENTO DE INCIDENTES DE SEGURIDAD

INSTRUCTIVO FECHA VERSIÓN

6. DESARROLLO DEL PROCESO

INSTRUCTIVO FECHA VERSIÓN

6.1 DIAGRAMA DE FLUJO

INSTRUCTIVO FECHA VERSIÓN

6.2 DESCRIPCION DE ACTIVIDADES

ROL RESPONSABLE PRODUCTO/SISTEMAS DE

Usuario 2. Registrar y clasificar

Analista Mesa 4. Diagnosticar y Solucionar PRO: Diagnóstico inicial

INSTRUCTIVO FECHA VERSIÓN

ROL RESPONSABLE PRODUCTO/SISTEMAS DE

Analista Mesa 5. Validar y Documentar Solución

Analista Mesa 7. Escalar a especialista

Especialistas 9. Escalar con el proveedor PRO: Incidente Escalado a

INSTRUCTIVO FECHA VERSIÓN

ROL RESPONSABLE PRODUCTO/SISTEMAS DE

Después de la recepción de un incidente, el Analista de Soporte de Primer Nivel ingresa en su pantalla

INSTRUCTIVO FECHA VERSIÓN

De acuerdo con los valores de la FR-GTE-02-029 Matriz Impacto Prioridad Urgencia.

El soporte de Primer Nivel valida la información suministrada en el incidente.

INSTRUCTIVO FECHA VERSIÓN

Los estados (tiempo de excepción) que podrá utilizar son:

10. Validar Solución de Tercer Nivel

11. Primera y Segunda notificación de la solución de solución

12. Cierre de incidente

Fin del procedimiento

INSTRUCTIVO FECHA VERSIÓN

- La Gestión de incidentes debe garantizar el registro de un caso para la atención de cualquier

9. RELACIÓN CON OTROS PROCESOS DE TI

FIRMA _ FIRMA _