Flujo de información para el manejo de incidentes...Gestor y dueño del proceso de Gestión de...

ARCHIVO: Procedimiento Gestión Incidentes CREADO:03/11/2009 VERSION DEL 07/05/2014

Nº. PÁG: 1/22

Emitido por: Grupo Metodología y Calidad - CSEI

Banco de Previsión Social

Gestión de Incidentes

Centro de Explotación BPS

Documento de

Procedimiento de


Versión 5.3


Nº. PÁG: 2/22




Registros del documento

REGISTRO DE REALIZACION:

COMPLETADO POR : Estela Hornos, Carolina Valverde

Fecha : 11/2009

AUTORIZADO POR : Estela Hornos

Estado : TRABAJO/REVISION/APROBADO

REGISTRO DE CAMBIOS:

Fecha Versión Responsable Cambio

10/11/09 2.0 Carolina Valverde Ajustes luego de revisión de Estela Hornos y Yaqueline Varela

13/11/09 3.0 Carolina Valverde Ajustes luego de revisión de Heber Rodríguez

20/11/09 4.0 Carolina Valverde Ajustes luego de realizado el testeo

23/11/09 4.1 Oscar Irland Ajustes luego de las pruebas

08/12/09 4.2 Carolina Valverde Ajustes luego de primera evaluación de funcionamiento

18/01/10 4.3 Carolina Valverde Ajustes varios Revisión final

25/02/10 4.4 Carolina Valverde Ajustes luego de implantación CSU

02/03/10 4.5 Carolina Valverde Revisión final

02/07/10 4.6 Estela Hornos Ajustes luego de la implantación CSU-Nivel 1

06/08/10 4.7 Carolina Valverde Ajustes luego de definición de Grupo Coordinador del Soporte Especializado

28/02/11 4.8 Carolina Valverde Aclaraciones respecto de incidentes que van al proyecto SE-BPS/IBM/BULL

05/10/11 5.0 Carolina Valverde Ajustes en procedimiento para incidentes urgentes

24/08/12 5.1 Carolina Valverde Inclusión de procedimiento para incidentes fuera de horario

27/02/13 5.2 Carolina Valverde Inclusión de procedimiento para incidentes de SE-BULL

12/04/13 5.3 Carolina Valverde Inclusión de procedimiento para incidentes de usuarios externos

15/09/13 5.4 Yaqueline Varela Revisión para ajustar roles y adecuaciones a la situación actual


Nº. PÁG: 3/22




REGISTRO DE REVISIONES/APROBACIÓN:

Fecha Hora Versión Revisor

09/11/09 Estela Hornos

09/11/09 Yaqueline Varela

12/11/09 Heber Rodríguez



26/09/13 Estela Hornos, Carolina Valverde



Nº. PÁG: 4/22




Contenido Objetivo Proceso ........................................................................................................................... 5

Alcance .......................................................................................................................................... 5

Proceso de gestión de Incidentes y Pautas Generales .................................................................. 6

Diagrama Proceso de Gestión de Incidentes ................................................................................ 6

Flujo Principal ................................................................................................................................ 6

Clasificación de incidentes ............................................................................................................ 7

Compromisos del Servicio ............................................................................................................. 8

Roles y responsabilidades ............................................................................................................. 9

Niveles de Atención para la Gestión de Incidentes ..................................................................... 10

Nivel 0 – CSU ............................................................................................................ 12

Nivel 1 – Mesas de Ayuda Funcionales o Técnica (Ofimática y Micros) .................. 12

Nivel 2 – Soporte Técnico de Desarrollo ................................................................... 12

Nivel 3 – Soporte Especializado (Centros de Explotación) ....................................... 13

1. Aplicativo en Producción en Servicios de Infraestructura .......................... 13

2. Aplicativo en Producción en cualquier Centro de Explotación ................... 13

3. Servicio de Guardias del Soporte Especializado es 7 días x 24 hs .............. 14

Escalamiento para la Gestión de Incidentes ............................................................................... 15

Gestión de Incidentes en Mantis ................................................................................................ 17

Pautas Generales ......................................................................................................... 17

Procedimiento para Incidentes de Usuarios Externos ................................................................ 20

1. Incidentes de Entidades Externas Consumidoras de Servicios de BPS ....... 20

2. Incidentes de Usuarios Externos de ATYR.................................................. 21

Procedimiento para la gestión de Solicitudes de Servicio ......................................................... 22

Anexos ......................................................................................................................................... 22


Nº. PÁG: 5/22




Objetivo Proceso [ISO/IEC 20000:2005]

- Restaurar el servicio acordado con el negocio tan pronto como sea posible o responder

a solicitudes de servicio

[ITIL (versión 2)]

- Restablecer la operación normal del servicio lo más rápido posible

- Minimizar el impacto adverso en las operaciones del negocio

- Asegurar que los niveles de calidad y disponibilidad de los servicios se mantengan en lo

establecido

Alcance El objetivo del documento es establecer el procedimiento que se llevará a cabo en CSEI para el Proceso de gestión de incidentes.

Quedan incluidos: el Centro de Servicios a Usuarios (CSU), las Mesas de Ayuda Funcionales, la Mesa de Ayuda Técnica (Ofimática y Micros), Área Gestión de Prácticas Centrales, los Centros de Desarrollo (Central, Prestaciones, Atyr, Horizontal) y los Centros de Explotación (ATEC-BPS, IBM, BULL).

Las herramientas de soporte al Proceso son: Set de Herramientas CISCO para la atención de las llamadas y mail, Formulario Web de Reporte de Incidentes (actualmente alcance sólo ATYR) para reporte y registro, Mantis para la gestión completa de incidentes.

ACCESO A HERRAMIENTAS

MANTIS Testeo: http://mantist.bps.net:50006/login_page.php

MANTIS Producción: http://mantisp.bps.net:50006/login_page.php

http://mantist.bps.net:50006/login_page.php

http://mantisp.bps.net:50006/login_page.php


Nº. PÁG: 6/22




Proceso de gestión de Incidentes y Pautas Generales

Diagrama Proceso de Gestión de Incidentes

Flujo Principal

Una solicitud de atención se pueden clasificar en:

• Incidente: cualquier evento que no forma parte de la operación estándar de un

servicio y que causa o puede causar, una interrupción de, o una reducción en la calidad

de ese servicio.

• Solicitud de Servicio: categoría de incidente que incluye, por ejemplo, requerimientos

de información, y/o consejo y/o documentación.

• Asesoramiento: es una sub categoría de Solicitud de Servicio que nos interesa

catalogar para identificar acciones específicas, por ej. capacitación.

Por mayor información, acceder a la definición de referencia del Proceso de Gestión de

Incidentes.

http://intranetbps/sitios/cyms/cyp/Definiciones%20de%20Referencia%20%20Procesos%20de%20Gestin/Forms/AllItems.aspx

http://intranetbps/sitios/cyms/cyp/Definiciones%20de%20Referencia%20%20Procesos%20de%20Gestin/Forms/AllItems.aspx


Nº. PÁG: 7/22




Clasificación de incidentes Se pueden asociar con esta clasificación las siguientes situaciones:

1. Incidentes de Severidad Alta o Alerta General: Prioridad 1

Estos incidentes refieren a problemas que afectan a múltiples usuarios, como ser la indisponibilidad de un servidor, base de datos o línea de comunicación.

También se clasifica como incidente urgente a toda indisponibilidad para usuarios externos, de los servicios en línea así como del sitio web de BPS.

2. Incidentes de Severidad estándar de aplicativos interactivos: Prioridad 1 o 2

Quedan incluidos en esta categoría todo incidente que se produzca en el uso habitual que hacen los usuarios de los distintos aplicativos (no procesos batch) y cuya causa no sea una de las especificadas en el ítem anterior.

3. Incidentes de procesos batch: Prioridad 2 o 3

Quedan incluidos en esta categoría los problemas que ocurren en aplicaciones operadas por los centros de Operaciones

4. Incidentes Entorno de trabajo personal (Solo afecta a 1 usuario): Prioridad 2 o 3

Quedan incluidos los incidentes que son atendidos por Ofimática (Micros y Soporte).

Impacto: determina la importancia del incidente dependiendo de cómo éste afecta a los procesos de negocio y/o del número de usuarios afectados.

Urgencia: depende del tiempo máximo de demora que acepte el cliente para la resolución del incidente y/o el nivel de servicio acordado en el SLA


Nº. PÁG: 8/22




Compromisos del Servicio Tiempos de Registrar/Categorización/Escalación: Es el tiempo dedicado por CSU en la atención al Usuario que llamó, para registrar/categorizar/diagnosticar la llamada que le permita determinar el grupo de atención/resolución.

Meta: Entre 2 y 3 minutos.

Tiempos de Asignación: Es el tiempo que transcurre entre la recepción del incidente y la asignación para su tratamiento.

La meta se determina según Nivel de Atención.

Nivel 3 (Soporte Especializado ) y Nivel 2 (Soporte Técnico): 5 minutos para su

asignación

Nivel 1 y 2 (Ofimática)

o Nivel 1- Ofimática-Soporte Inicial : 10 minutos para su asignación y

comunicación con el usuario

o Nivel 2- Ofimática-Micros : 60 minutos para su asignación y

comunicación con el usuario

Incidentes Fuera de Hora: 15 min en el nivel que corresponda

Tiempos de Resolución de Ofimática: Es el tiempo dedicado para diagnosticar e intentar dar solución:

Ofimática-Soporte Inicial = Entre 15 y 30 minutos (si dentro de ese plazo estima que

no podrá resolverlo, debería ser pasado a Nivel 2 - Micros)

Si es Ofimática-Micros = Dentro de las 24 horas

Si es Ofimática-Tercerizado (equipos con garantía) = A definir

o Se envía al Proveedor, quien diagnostica y hace gestión de garantía (se lleva el

equipo) dentro de las … Hs

o Tiempo de devolución del equipo: … Hs

Si es Ofimática-Tercerizado (equipos sin garantía) = Sonda diagnostica y repara dentro

de las 72 hs. Si no es posible la reparación debe dejar backup hasta 45 días, si no lo

puede reparar en ese lapso lo debe sustituir por uno de igual porte.

En todos los casos, pueden existir situaciones que ameriten más tiempo que el establecido, en esos casos dejar nota indicando los motivos, para su análisis junto a los indicadores correspondientes.


Nº. PÁG: 9/22




Roles y responsabilidades

Gestor y dueño del proceso de Gestión de Incidentes: Responsable de que el proceso para

la gestión de incidente se realice de acuerdo a lo previsto en este procedimiento y que

verifique que todos los incidentes están siendo atendidos dentro de los plazos

establecidos. Es el coordinador entre los diferentes sectores involucrados en la resolución

del mismo.

Referente del Soporte Especializado (SITO):

o Responsable de gestionar los reportes que son responsabilidad del/los grupo/s de

Soporte Especializado de SITO según este procedimiento y en coordinación con el

Gestor y Dueño del Proceso.

o Seguimiento de los reportes que son responsabilidad del/los grupo/s de Soporte

Especializado de SITO en horario normal, que no han sido atendidos/asignados a

ninguna persona para su atención, o ha sido asignado pero ocurre una demora

importante en la resolución.


Especializados (SITO, BULL, IBM) que llegan fuera de hora y que deben ser

atendidos/asignados dentro de los plazos de asignación establecidos, como así

también gestionar cuando ocurre una demora importante en la resolución.

Nota: En Horario Normal este rol es cumplido por personas asignadas a tal fin por cada

Servicio y Fuera de Hora por el Grupo Operaciones de BPS.

Referente de Incidentes de Soporte técnico (CSDX):

o Responsable de gestionar los reportes que son responsabilidad del/los grupo/s de

Soporte Técnico (CSDX) según este procedimiento y en coordinación con el Gestor y

Dueño del Proceso.


Técnico (CSDX), que no han sido atendidos/asignados a ninguna persona para su

atención, o ha sido asignado pero ocurre una demora importante en la resolución.

Responsable de atender incidentes por grupo:

o Responsables de diagnosticar/resolver los incidentes. Cada grupo debe definir cómo

implementará la asignación de sus integrantes dependiendo de las características

(cantidad de integrantes, organización del equipo). Su coordinador definirá si esta

responsabilidad estará asignada a un par de personas, a varias, o a todo el grupo.

Las personas que cumplen estos roles y los datos de contacto se encuentran detallados en el Algoritmo de Escalación.

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Algoritmo%20de%20escalaci%C3%B3n.xls


Nº. PÁG: 10/22




Niveles de Atención para la Gestión de Incidentes La Figura 1 muestra el flujo de información a través de los distintos niveles de atención para la Gestión de Incidentes en BPS.

Escenario Final – Explotación BPS

Grupos de SoporteNivel 2

Mesas de Ayuda Funcional

Nivel 1

CSU (Centro de Servicios a Usuarios)

UsuariosCentro de Explotación

Nivel 3

COMU Soporte

EspecializadoSCOR

Soporte Especializado

SERV Soporte

EspecializadoBD

Soporte EspecializadoALERTAS GRALES

Referentes funcionales de

aplicativos

Referentes técnicos de aplicativos

Referentes técnicos ATEC

CSDX Soporte Técnico

SE-BPS/IBM/BULL

AU-X (Ej. CAUSA)

Se mueve el incidente por Mantis al grupo SE-BPS/IBM/BULLCuando se sabe que ATEC debe resolver el incidente, pero igualmente es necesario poner en conocimiento a los demás CS Exlp.

Cuando se conoce que el CS Expl que debe resolver el incidente es tercerizado.

Cuando no se conoce cuál es el CS Expl que debe resolver el incidente.

Se mueve el incidente por Mantis al grupo correspondiente de ATECCuando se sabe que es ATEC quien resuelve el incidente

SE-BPS(ATEC)

2

SE-RCOR

OFIMÁTICASoporte Inicial

1

CSU

Formulario CAUSA

CSEI_CSU

3000

Figura 1 - Flujo de información


Nº. PÁG: 11/22




La Figura 2 muestra las responsabilidades de los distintos niveles de atención.

Tener en cuenta que todos los niveles de atención podrán recibir, registrar y rutear incidentes,

respetando las definiciones para cada caso.

Figura 2 - Responsabilidades


Nº. PÁG: 12/22




Nivel 0 – CSU

El CSU es el primer responsable de recibir, registrar y rutear todos los incidentes que llegan al

Centro, ya sea a través de llamadas telefónicas o vía mail. 1Informa al solicitante el Nro. de

ticket correspondiente por teléfono y por mail.

El ruteo se realiza según los algoritmos de escalación definidos, a través de MANTIS, salvo los

derivados a CAUSA que se realiza utilizando el formulario Web de Reporte de incidente.

En caso de que el CSU pueda resolver el incidente (por ejemplo, si se trata de una solicitud de

información, si ya existe un incidente del mismo tipo registrado), el mismo se “cierra” sin

escalar, agregando la nota de resolución correspondiente.

Para todos los casos, el CSU es responsable del seguimiento de los incidentes.

Nivel 1 – Mesas de Ayuda Funcionales o Técnica (Ofimática y Micros)

Si el Nivel 1 es responsable del diagnóstico y solución, se “asigna” el incidente y al resolverlo lo

pasa al estado ‘resuelto’ y también lo “cierra".

Si no es responsable de su resolución, el incidente se escala (“mueve”) al grupo de atención

que corresponda.

Nivel 2 – Soporte Técnico de Desarrollo

Si el Nivel 2 es responsable del diagnóstico y solución, se “asigna” el incidente y se pasa al

estado ‘resuelto’ una vez se haya encontrado solución al mismo.

En caso de que el incidente haya sido escalado a través de Mantis, se retorna (“mueve”) al

Proyecto que lo reportó. En caso contrario, la comunicación y validación con el usuario se

realiza por fuera de Mantis, y se “cierra” el incidente (caso de excepción para cierre).

Si no es responsable de su resolución, el incidente se escala (“mueve”) al grupo de atención

que corresponda.

1 Si el usuario utilizó el Formulario Web para reportar el incidente, éste graba automáticamente en

Mantis y se continúa su flujo normal de atención, Nivel 0-CSU no participa en el ciclo.


Nº. PÁG: 13/22




Nivel 3 – Soporte Especializado (Centros de Explotación)

El Nivel 3 es responsable de diagnosticar y “resolver” (o participar en la resolución) de los

incidentes involucrados en los escenarios descriptos a continuación.

En caso de que la atención del incidente sea responsabilidad de algún grupo de SITO, alguien

se lo debe “asignar”, y pasarlo al estado ‘resuelto’ una vez se haya encontrado solución al

mismo. Luego, se retorna (“mueve”) al Proyecto que lo reportó.

Tanto si la atención del incidente es responsabilidad de SITO o de alguno de los Servicios

Especializados de IBM o BULL, cada Centro debe especificar si corresponde o no su atención.

1. Aplicativo en Producción en Servicios de Infraestructura

Caso 1 de Figura 1 - Flujo de información. Se sabe que es SITO (ex ATEC) quien

resuelve el incidente, es decir, no se requiere intervención de los demás Centros de

Explotación.

Se distinguen tres casos:

1. Si, quien deriva el incidente identifica el grupo que debe atender el incidente

(subproyectos SE-BASE DE DATOS, SE-SERVIDORES, SE-COMUNICACIONES, SE-

SERVICIOS CORPORATIVOS), lo “mueve” directamente.

2. Cuando no se puede identificar qué grupo de SITO debe atender el incidente, o

existen dudas al respecto, o se identifica que el incidente puede involucrar a

varios grupos, el mismo se mueve al grupo SE-BPS (ATEC). Este Proyecto contiene

los integrantes de los 4 grupos: BASE DE DATOS, SERVIDORES, COMUNICACIONES

y SERVICIOS CORPORATIVOS.

3. Cuando el incidente corresponde a un aplicativo de RCOR, se mueve al Proyecto

SE-RCOR.

2. Aplicativo en Producción en cualquier Centro de Explotación

Caso 2 de Figura 1 - Flujo de información. Cuando no se conoce a cuál Centro de

Explotación le corresponde la solución, o es un aplicativo en Producción en el Centro

de Explotación de BPS pero que pueden requerir intervención de los demás centros, o

es un aplicativo que se explota en los centros de IBM o BULL.

Mediante la herramienta Mantis se escala (“mueve”) el incidente al Proyecto SE-

BPS/IBM/BULL, lo cual generará el envío de mail a los integrantes de la casilla

‘Incidentes’ que contiene a los integrantes de todo SITO, BULL e IBM.

Importante: incluir en la descripción del incidente el Centro de Explotación que debe

resolver el incidente (si se conoce).

Si la atención del incidente corresponde únicamente al CSBULL, entonces el mismo

servicio de BULL moverá el reporte al Sub-proyecto SE-BULL, lo cual también generará

el envío de mail a los integrantes de la casilla ‘Incidentes’. Una vez el incidente haya


Nº. PÁG: 14/22




sido solucionado, se devuelve (mueve) al Proyecto SE-BPS/IBM/BULL en estado

“resuelto”.

Cuando se conoce el Servicio de Infraestructura (BULL o IBM) el mismo se deriva

directamente a BULL o a IBM por mail copiando a las contrapartes correspondientes

(Nivel 1 –Atención a Usuarios y Nivel 2 – Soporte Técnico)

3. Servicio de Guardias del Soporte Especializado es 7 días x 24 hs

Los Servicios de Soporte Técnico y Especializado son de Lunes a Viernes de 9.00 hs. a 17.00 hs.

La atención del Centro de Servicios a Usuarios (CSU) es de 8:00 hs. a 20:00 hs.

Entre las 20:00 y 8:00 hs, fines de semana y feriados, debe comunicarse con el 3100.

El servicio de guardia está establecido para los siguientes casos:

Si corresponde a un incidente del Área de la Salud.

Si corresponde a un servicio de correo electrónico o Internet (Sitio web y servicios

en línea).

Entidades Externas, con las que se ha acordado este servicio

Ante la duda y si el usuario insiste en que se trata de un asunto urgente y no es

posible esperar.

Nota: Si el incidente es derivado por el Área de la Salud (AU-SP-SALUD o AU-UNAF) o por ATYR (Conexión Remota-0800 5556) o por Entidades Externas, y no es suficiente la información se debe solicitar mayor detalle.

Si no se recibe más información se deja constancia en MANTIS y se continúa la gestión en el horario normal.

Para el caso de Incidentes fuera de horario en ATYR (Conexión Remota), ver Procedimiento para Reporte de Incidentes Fuera de Horario – Conexión Remota.

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Procedimiento%20Reporte%20Incidentes%20Fuera%20Horario%20-%20Conexi%C3%B3n%20Remota.pdf


Nº. PÁG: 15/22




Escalamiento para la Gestión de Incidentes La Figura 3 muestra el diagrama básico de escalación para la gestión de incidentes en BPS.

La escalación de los incidentes siguen las definiciones del Algoritmo de Escalación.

Diagrama básico de Escalación - Gestión de Incidentes (complementar con Algoritmo de Escalacion)

CSUNivel 1 – AU y

OfimáticaNivel 2 – Soporte

TécnicoNivel 3 – Soporte

Especializado

Es incidente?Solo le ocurre a Usuario que

llama?

Ofimática(Micros, SONDA)

si si

Hardware, Pc, Impresoras,

Instalaciones? Herramientas de

Ofimática?

Ofimática(Soporte Inicial)

Es en aplicaciones de Negocio?

AU(Mesas de Ayuda

Funcionales)si

Existe reporte en “Alertas

Generales”?

Soporte Especializado

si

Ordenes de Servicio (se escalan de igual

manera que incidentes. Solo se

categoriza la llamada)

No

Solo en casos establecidos en

algoritmo de escalación

no

si

Informar al Usuario

No

Si no logra determinar

problema consultar a Supervisor

No

No

ST-CSDX(Soporte Técnico

de Desarrollo)

Requiere Soporte Técnico?

SI

Requiere Soporte

Especializado?

Figura 3 - Diagrama de Escalación

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Algoritmo%20de%20escalación.xls


Nº. PÁG: 16/22




La Tabla 1 muestra cómo se lleva a cabo el escalamiento jerárquico y la comunicación del incidente.

Dependiendo de la severidad y del tiempo transcurrido sin atención, es decir, nadie se lo ha “asignado”, se define a quien debe escalarse.

Prioridad Tiempo de asignación desde el reporte

Acción

Alertas Generales , Aplicaciones OnLine Críticas e Incidentes de Usuarios Externos

1 5’ Llamar a los grupos de Soporte Especializado que correspondan para verificar que el reporte del incidente se haya recibido.

Comunicar a la Alta Gerencia CSEI, para que estén informados de la situación.

1 10’ Escalar el incidente al gestor y dueño del Proceso y/o al Grupo coordinador de Soporte Especializados

1 20’ Escalar el incidente a la alta gerencia de CSEI

Aplicaciones OnLine No Críticas, Procesos Batch Críticos y Ofimática

2 5’ Llamar a los grupos de Soporte Especializado que correspondan para verificar que el reporte del incidente se haya recibido

2 10’ Escalar el incidente al gestor y dueño del Proceso y/o al Grupo coordinador de Soporte Especializados

2 25’ Escalar el incidente a la alta gerente de CSEI

Aplicaciones Batch No Críticos y Ofimática

3 5’ Llamar a los teléfonos de los grupos de Soporte Especializado que correspondan para verificar que el reporte del incidente se haya recibido

3 15’ Escalar el incidente al gestor y dueño del Proceso y/o al grupo coordinador de Soporte Especializados

3 30’ Escalar el incidente a la alta gerente de CSEI

Tabla 1 - Escalamiento Jerárquico


Nº. PÁG: 17/22




Gestión de Incidentes en Mantis A continuación se describe cómo es soportado el proceso de Gestión de Incidentes definido para BPS en la herramienta MANTIS.

Pautas Generales

Todos los incidentes deben ser gestionados a través de la herramienta Mantis. Existen

grupos funcionales que todavía no se han incorporado al uso de Mantis; en esos casos los

incidentes serán igualmente escalados reenviando el mail generado por la herramienta.

Es imprescindible que la persona que está resolviendo el incidente se lo “asigne” en la

herramienta, de manera tal de que el resto del grupo y los demás Sectores involucrados

conozcan este hecho.

Todos los incidentes resueltos deben “moverse” al Proyecto que reportó el mismo en estado “resuelto”, salvo las excepciones que se establezcan.

Cierre de Incidentes y Solicitudes de Servicios: Los Servicios de Asistencia a Usuarios (Mesas

de ayuda funcionales, Mesa de Ayuda Técnicas y CSU), luego de corroborar la solución y

“cerrar” el incidente, informan a los Usuarios que reportaron el incidente. 2

Se pueden dar las siguientes situaciones:

1) Si “Resuelve” Nivel 3, devuelve (“mueve”) al proyecto que reportó.

SITO NO “cierra” incidentes, salvo que:

la atención sea directa con el usuario, es decir, ya estará verificando su solución (ej. instalación de un puesto de red)

detecten el incidente (por lo tanto también lo registran) y solo ellos pueden verificar la correctitud de la solución (ejs. cuando detecta una caída en comunicaciones, en un servidor, en una base de datos)

2) Si el Nivel 1 no tiene acceso a MANTIS, informa la correctitud de la solución y solicita a Nivel 0 su “cierre”, en caso contrario lo devuelve (“mueve”) al proyecto que lo reportó.

3) En todos los demás casos, los Niveles 0 y 1 son los responsables de verificar y “cerrar”.

Nota: Se realizan hasta 2 llamados o mail para su verificación. Si no se logra comunicación, se envía mail de aviso que se cierra y que si persistiera el incidente, se abre un nuevo caso.

Todas las comunicaciones deben quedar registradas en cada incidente: desde la descripción del error cuando se reporta, hasta las notas que cada grupo de atención escribe para facilitar el diagnóstico, pistas, líneas de investigación que se están transitando, hasta la solución brindada.

2 Pueden realizar la comunicación sobre el mail generado desde el formulario web (en caso que se utilice

el mismo), o sobre un mail nuevo (si no se utiliza formulario web) o telefónicamente


Nº. PÁG: 18/22




Diagrama de estados

Descripción de los estados en Mantis

Nueva: cuando se crea (registra) una nueva incidencia. El incidente se registra en el

Proyecto al cual se pertenece, y si corresponde escalar se MUEVE al Proyecto que le

dará atención.

Asignada: cuando se comienza con el diagnóstico para dar solución a una incidencia.

Nota: las incidencias se asignan a cada uno ([Mí] en Mantis) o es asignada por un

coordinador.

Escalada: antes de mover un incidente a otro proyecto que haya sido diagnosticado

pero no solucionado, se documenta en “notas” lo realizado y se cambia a estado

“escalada”, con el objetivo de distinguir entre los incidentes “nuevos” para un

determinado proyecto del resto.

En espera: este es el caso en que se está a la espera de un tercero para resolver una

incidencia, o por razones ajenas no es posible resolverla en el momento (ejemplos:

cuando no se puede comunicar con un funcionario, cuando se está esperando la


Nº. PÁG: 19/22




respuesta de un proveedor) o no se pudo dar una solución alternativa y hay que

esperar por un cambio.

Más Información: cuando no es suficiente la información registrada para una

incidencia y no fue posible obtenerla ya sea por teléfono o por mail. Nota: en este

caso también es necesario mover el incidente al grupo que debe brindar más

información, e incluir cuál es la información complementaria que se requiere.

(Aclaración: este estado ya existía pero se llamaba, “Se necesitan más datos”)

Devuelta: si el incidente es movido (escalado) a un proyecto (grupo de atención) que

no corresponde su resolución o la información proporcionada no aporta al

diagnóstico, el mismo es devuelto y movido al proyecto origen.

Reclamada: cuando el tiempo transcurrido desde que se movió (escaló) el incidente

excede el tiempo comprometido.

Resuelta: cuando el incidente está resuelto. Es necesario incluir las notas de resolución

(aclarando cómo fue resuelto el incidente), y moverlo al proyecto origen, salvo las

excepciones que se establezcan.

Cerrada: cuando se verifica o se confirma con el usuario que el incidente se encuentra

resuelto, entonces se cierra o cuando se proporcionó una solución alternativa y se

continúa con un cambio ya gestionado (log de pendientes o RFC que se documenta en

el dato: “Nro. Solicitud Cambio”). El cierre de los incidentes lo realizan el Nivel 0 (CSU)

y los Niveles 1 (Mesas de Ayuda Funcionales, Ofimática y Micros).

Excepción: cuando el incidente es derivado al Proyecto SE-BPS/IBM/BULL, es el

referente del Centro (CSDX) que derivó el incidente quien tiene la responsabilidad de

volver a moverlo para su cierre, ya sea a un proyecto funcional (si requiere validación

del usuario final) o a un proyecto técnico (si solo requiere validación técnica).


Nº. PÁG: 20/22




Procedimiento para Incidentes de Usuarios Externos

1. Incidentes de Entidades Externas Consumidoras de Servicios de BPS

El siguiente diagrama muestra el procedimiento de atención de incidentes para entidades

externas a BPS que utilizan sus servicios.

INCIDENTES ENTIDADES EXTERNAS

CSU – Centro de Servicios al Usuario

Montevideo: 19973000Interior: 21997300024000151 int. 3000

SITO-OperacionesMontevideo: 19973100

Interior: 21997310024000151 int. 3100

Se genera un número de incidente (Mantis) y se

informa al usuario

Se genera un número de incidente (Mantis) y se

informa al usuario

Se mueve al SOPORTE ESPECIALIZADO

Se canaliza con la guardia y se mueve al SOPORTE

ESPECIALIZADO

Se informa al usuario la solución

Días hábiles

de 8 a 20hrs

Días hábiles de 20 a 8hrs

Días no hábiles

Nota: Los Soportes Especializados por Servicio están especificados en el Algoritmo de Escalación.




Nº. PÁG: 21/22




Excepciones al Procedimiento General

El cierre de los incidentes (y por lo tanto la comunicación con el usuario externo) lo

podrá realizar tanto el CSU como el grupo de Operaciones.

Los incidentes se escalan directamente al Nivel 3 (SE-SERVIDORES), sin pasar por el

Nivel 2 (Soporte Técnico de Desarrollo).

Se cuenta con una lista de los distintos referentes de las entidades que están

habilitados para llamar junto con sus datos de contacto.

HERRAMIENTA MANTIS

Los incidentes de usuarios externos contendrán el valor “Incidente Usuario Externo”

en el campo “Clasificación Llamada”, de manera de diferenciarlo de los incidentes de

usuarios internos.

Se propone utilizar la nomenclatura [USU_EXT] como inicio del “Resumen” del

incidente (que corresponde al Asunto del mail), de forma tal de identificar

rápidamente que corresponda a un incidente de usuarios externos.

Ver Comunicado para Atención de Incidentes de Usuarios Externos

2. Incidentes de Usuarios Externos de ATYR

Procedimiento de Atención de Incidentes Fuera de hora (Conexión Remota)

En este procedimiento se establece la forma en que se reportan los incidentes

generados por los usuarios externos atendidos por Conexión Remota, y que requieren

intervención técnica antes de las 9:00 o luego de las 17:00 hs.

Ver Procedimiento para Reporte de Incidentes Fuera de Horario – Conexión Remota en Activos Generales

http://intranetbps/sitios/activos_generales/Procesos%20y%20Calidad/Comunicado%20-%20Gestión%20de%20Incidentes%20Usuarios%20Externos.pdf




Nº. PÁG: 22/22




Procedimiento para la gestión de Solicitudes de Servicio

Las solicitudes de servicio de usuarios finales son también gestionadas a través de Mantis.

Para ello se clasifica la llamada en ‘Solicitud de servicio’ o ‘Asesoramiento’, y se sigue el mismo

procedimiento que para los incidentes.

En caso de que la solicitud requiera un “No Regular” se genera una solicitud en MANTISITO y

se relacionan ambas hasta su solución y cierre.

NOTA: los tiempos de atención para solicitudes de servicio no son los mismos que para

incidentes.

Anexos

1. NOMENCLATURA

Funcionales (Nivel 1)

AU-NombreAreaFuncional

Soporte Técnico (Nivel 2)

CSDX-ST-NombreGrupo (si aplica)

Soporte Especializado (Nivel 3)

SE-NombreGrupoSoporte

Ejemplo: SE-BPS (ATEC)

2. GLOSARIO

CSU – Centro de Servicios a Usuarios.

AU – Atención a Usuarios

ST – Soporte Técnico

SE – Soporte Especializado

CSDx – Centros de Servicios de Desarrollo (x=P (Prestaciones), C (Central), A (ATYR), H

(Horizontal)

ATEC – Asistencia Técnica = Centro de Explotación BPS = Soporte Especializado = SITO

= Servicios de Infraestructura Tecnología y Operaciones (en nueva estructura)

Flujo de información para el manejo de incidentes...Gestor y dueño del proceso de Gestión de...

Documents

Transcript of Flujo de información para el manejo de incidentes...Gestor y dueño del proceso de Gestión de...