Gestión de incidentes en Entel

PROCESO DE GESTIÓN DE INCIDENTES
ENTEL
SGD-ITIL-02
USO INTERNO
Código: SGD-ITIL-02
PROCESO DE GESTIÓN DE INCIDENTES Versión: 1.0
Fecha: 18/09/2015
Página Página 2 de 40
CONTROL DE VERSIONES
Fecha Descripción del Cambio Versión Responsable
18/02/2015 Versión Inicial 1.0 Max Pizarro
Actualización de la documentación en el Oscar Narváez

27/06/2016 1.1
formato de procesos ITIL Evelyn Gonzales
Nombre y Apellidos Cargo Fecha

Elaborado por: Max Pizarro Gestor de Incidentes 18/02/2015
Revisado por: Cesar Ramirez Gerente de Operaciones 18/09/2015

e Infraestructura
Aprobado por: Cesar Ramirez Gerente de Operaciones 18/09/2015
e Infraestructura
Fecha: 18/09/2015
Contenido
1. OBJETIVO............................................................................................................................................................... 4
2. ALCANCE................................................................................................................................................................ 4
3. DEFINICIONES........................................................................................................................................................ 4
4. ROLES Y RESPONSABILIDADES ............................................................................................................................ 5
5. CARACTERÍSTICAS............................................................................................................................................... 12
6. POLÍTICAS GENERALES ....................................................................................................................................... 16
7. DESARROLLO DEL PROCESO .............................................................................................................................. 20
8. MATRIZ RACI ....................................................................................................................................................... 34
9. FACTORES CRÍTICOS DE ÉXITO Y MONITOREO DE DESEMPEÑO ................................................................... 35
Fecha: 18/09/2015
1. OBJETIVO
El objetivo principal del proceso de Gestión de Incidentes es restaurar la operación normal del
Servicio tan pronto sea posible y minimizar el impacto sobre la operación del Negocio de
manera que se mantengan los niveles de calidad y disponibilidad del Servicio acordados. La
'Operación Normal del Servicio' se define como la operación del Servicio dentro de los límites
establecidos en los Acuerdos de Nivel de Servicio (SLAs).
Atender todos los incidentes presentados por los usuarios de ENTEL Perú, cumpliendo con los
Niveles de Servicio establecidos.
Los objetivos detallados del proceso de Gestión de Incidentes son:
• Reducir el tiempo destinado a la solución de los Incidentes.

• Documentar las actividades realizadas para la solución de un Incidente.
• Identificar los Incidentes antes de que el cliente los identifique.
• Generar reportes mostrando la mejora en el cumplimiento de los Acuerdos de Niveles de
Servicio.
• Mejorar de manera constante y consistente la percepción de los servicios de TI a través de
un enfoque profesional en la resolución rápida de los Incidentes.
2. ALCANCE
El alcance está acotado solo a los usuarios de ENTEL Perú y externos que utilicen los servicios
de la Vicepresidencia de Sistemas y Procesos (VP de S & P).
El proceso de Gestión de Incidentes cubre todo tipo de fallas que interrumpa o pueda
interrumpir las aplicaciones que soportan los servicios de la Vicepresidencia de Sistemas y
Procesos en cualquier punto que se encuentre operando y que dan soporte al negocio.
El proceso de Gestión de Incidentes es el responsable de gestionar el ciclo de vida de todos los

Incidentes. Los Incidentes pueden ser identificados y reportados por:
• El personal de las diferentes áreas de la Vicepresidencia de Sistemas y Procesos así
como sus socios Tecnológicos (Torres y sus proveedores).
• Herramientas de monitoreo de eventos.
• Usuarios
3. DEFINICIONES
• Incidente Normal: Cualquier evento que no es parte de la operación estándar de un servicio,

y que provoca o puede causar la interrupción parcial del servicio, el cual puede ser
restablecido por cualquier solución temporal tomada de la base de datos de errores
conocidos. También es un Incidente la falla de un Elemento de Configuración (CI) que aún no
impacta el Servicio.
Fecha: 18/09/2015
• Incidente Mayor: Cualquier evento que provoca o puede causar la interrupción completa de
la operación y para el cual no existe solución temporal que aplicar. Dicho incidente tiene la
máxima prioridad para restablecer el servicio tan pronto como sea posible.
• SLA: Acuerdo de Niveles de Servicios (Service Level Agreement), es el contrato escrito entre
la Vicepresidencia de Sistemas y Procesos de ENTEL Perú y sus clientes, con el objeto de
acordar la entrega del servicio, así como las responsabilidades mutuas.
• Procedimiento: Descripción detallada de una serie de pasos, claramente definidos los
cuales son necesarios para realizar operaciones específicas conforme a normas aplicables.
• Usuario: Personas que tienen una cuenta de red para fines de negocio.
• Cambio: La adición, modificación o eliminación de un Servicio o componente de Servicio
autorizado, planeado o soportado así como su documentación asociada.
• Problema: La causa desconocida de uno o más Incidentes. La causa normalmente no se
conoce en el momento en el que el Problema se registra.
• Workaround: Solución temporal para resolver en menor tiempo los Incidentes
• ITSM: Information Technology Service Management
• KPI: Indicador Clave de Desempeño (Key Performance Indicator)
• Soporte de Primer Nivel: Referente a la Mesa de Servicio, donde los involucrados en la
misma se enfocan en la resolución de Incidentes. Cada nivel contiene capacidades más
especializadas, o tiene más tiempo u otros Recursos.
• Soporte de Segundo Nivel: Referente a Grupos de Soporte envueltos en la resolución de
Incidentes e investigación de Problemas con habilidades especializadas.
• Herramienta (por especificar): Es una solución de Administración de Servicios de TI (ITSM)
implementada en ENTEL, donde se utiliza el módulo de gestión de Incidentes, servicios,
cambios y problemas, para el registro, control, seguimiento y gestión.
4. ROLES Y RESPONSABILIDADES
4.1. Roles del Proceso
Para el modelo de Gestión de Incidentes se tienen identificados seis roles principales que son los
que se enlistan a continuación:
• Dueño del proceso

• Administrador de Incidentes
• Ejecutivo de Primer Nivel (Mesa de Servicios)
• Personal de Soporte de Segundo Nivel
• Proveedor Externo
• Usuario
4.1.1. Dueño del Proceso
a. Perfil del Rol

Fecha: 18/09/2015
Tendrá la responsabilidad de principio a fin de asegurar que el Proceso de Gestión de

Incidentes funciona y se desarrolla. La finalidad del Dueño de Incidentes es asegurar que el
proceso sea eficiente, efectivo y cubra los requerimientos del Negocio.
La persona a quien se le asigne el rol de Dueño del proceso de Incidentes asegurará el flujo
del proceso y la integración con los otros procesos.
En general, el Dueño del Proceso de Incidentes debería reunir las siguientes características:
• Dirigir y controlar el proceso bajo una visión integral.
• Tener sólidas competencias en cuanto al proceso.
• Entendimiento de la Infraestructura y Aplicaciones de TI.
• Comprender al negocio y a la organización TI.
• Deseable certificación en Gestión de Servicios de TI (Fundamentos), certificaciones
intermedias relacionadas con el proceso (Service operation).
• Excelente comunicación y habilidades de presentación.
• Entendimiento del funcionamiento de ENTEL Perú y cómo la Vicepresidencia de
Sistemas y Procesos contribuye a la entrega de los Servicios.
• Excelente habilidad de manejo de personal y administración.
• Capacidad analítica y estadística.
• Habilidad para interactuar con los usuarios y las Áreas internas de la Vicepresidencia
de S & P de ENTEL Perú.
• Orientación de servicio al cliente.
b. Responsabilidades del Dueño del Proceso de Incidentes
Las responsabilidades se dividen en los siguientes tres aspectos:

• Diseño e Implementación del Proceso.- Conformación del modelo del proceso y los
controladores del proceso (aspecto y su implementación en la organización).
• Controles del Proceso.- Detalle de los controles, en el cual se consideran elementos
que controlan al proceso como: Objetivo, alcance, políticas, métricas y reportes.
c. Actividades del Dueño del Proceso de Incidentes
Las actividades asociadas con este rol pueden ser realizadas en conjunto con el
Administrador de Incidentes e incluso pueden ser delegadas, pero siempre con la supervisión
del Dueño del Proceso de Incidentes. A continuación se mencionan:
• Diseñar políticas y procedimientos.
• Diseñar los Indicadores Clave de Desempeño (KPIs).
• Analizar los reportes de desempeño del proceso.
• Identificar y emprender mejoras en la herramienta, proceso, mecanismos de control.
• Comunicar cambios y mejoras al Administrador del Proceso.
• Revisar, priorizar y evaluar los cambios propuestos al proceso.
• Atender reuniones de nivel directivo y/o gerencial para evaluar el impacto de las
decisiones organizacionales dentro del proceso de Incidentes.
• Controlar y administrar la integración entre varios procesos.
• Promover la visión de servicios a nivel directivo y/o gerencial.
Fecha: 18/09/2015
4.1.2. Administrador de Incidentes
a. Perfil del Rol
El Administrador de Incidentes reporta al Dueño del Proceso de Incidentes y lleva a cabo

actividades operativas y gerenciales que son demandadas por el proceso. Tiene
responsabilidad en un área o en una estructura en específico de la organización, participa en
el diseño, implementación y ejecución del proceso, siendo parte del equipo liderado por el
Dueño del proceso de Incidentes.
El Administrador de Incidentes es responsable de la identificación de oportunidades de

mejora y revisiones en el uso del proceso a un nivel operacional. Esto asegura la conformidad
del proceso por parte de los Analistas de Incidentes.
Finalmente, el Administrador de Incidentes es responsable de suministrar reportes a los

responsables de otros procesos de Gestión de Servicios del área de Sistemas. También será
responsable por el manejo de las salidas del proceso según los Acuerdos de Nivel de Servicio
(SLAs). Este rol actúa como guardián de la calidad del proceso y es responsable de asegurar
que el proceso es usado correctamente.
En general el perfil ideal para el Administrador de Incidentes es el siguiente:

• Recomendable tener certificación en Gestión de Servicios de TI (Fundamentos) y
certificaciones intermedias relacionadas con el proceso (Service Operation y
Operation Support and Analysis).
• Conocimiento y experiencia en el manejo de contratos y/o en roles de Gestión de
Proveedores.
• Comprende los Servicios que la Vicepresidencia de Sistemas y Procesos de Entel
Perú entrega a sus clientes del negocio.
• Debe ser flexible y convincente en cuanto a la adopción del proceso por parte de la
VP de S & P, debido a que no posee la autoridad para forzar a usar el proceso.
• Excelente habilidad de manejo de personal y gestión.
• Capacidad analítica y estadística.
• Excelente comunicación.
• Habilidad de interactuar con los usuarios y las diferentes Áreas de la VP de S & P
de Entel Perú
• Habilidades de negociación.
• Conocimiento técnico general sobre la infraestructura tecnológica de ENTEL Perú
b. Objetivo del Rol
• Responsable por la operación del día a día del proceso.

• Organizar al equipo de Gestión de Incidentes.
c. Responsabilidades del Administrador de Incidentes
Las responsabilidades se dividen en los siguientes tres aspectos:

Fecha: 18/09/2015
• Diseño e Implementación del Proceso.- Conformación del modelo del proceso y los
controles del proceso y su implementación en la organización.
• Controles del Proceso.- Detalle de los controles, en el cual se consideran elementos
que controlan al proceso como: Objetivo, alcance, políticas, métricas y reportes.
• Actividades del Proceso:
o Procurar el uso correcto del proceso.
o Proveer a nivel ejecutivo y a otros procesos la información de la Gestión del
Proceso.
o Asegurar que se cumplen los Indicadores Clave de Desempeño (KPIs) de
Gestión de Incidentes.
o Asegurar que el proceso se desempeña eficaz y eficientemente.
o Maximizar el desempeño de personas, procesos, tecnologías y dirección.
d. Actividades del Administrador de Incidentes
Las actividades son las siguientes:

• Monitorear y controlar el proceso, empleando Indicadores Clave de Desempeño
(KPIs) tanto cuantitativos como cualitativos.
• Generar y suministrar reportes del manejo de incidentes.
• Coordinar y proveer capacitación del proceso al personal involucrado.
• Si fuera necesario fungir como punto de escalamiento para los analistas de incidentes
• Proporcionar asesoría a los analistas de incidentes en la utilización correcta del
proceso.
• Identificar oportunidades y generar propuestas para mejoras con respecto a la
herramienta, personal, entrenamientos, proceso, procedimientos e instrucciones de
trabajo.
• Periódicamente revisar el proceso y proveer retroalimentación al Dueño de
Incidentes.
• Administrar al equipo de Gestión de Incidentes.
• Proporcionar información al personal de la Mesa de Servicios que le permita
desempeñar eficientemente sus actividades. Esto incluye información del proceso,
conocimientos técnicos, registro y consulta de información acerca de Errores
Conocidos.
4.1.3. Ejecutivo de Primer Nivel (Mesa de Servicios)
a. Perfil del Rol
• Recomendable tener certificación en Gestión de Servicios de TI (fundamentos).

• Capacidad analítica.
• Experiencia en soporte técnico para solucionar Incidentes en su área de dominio.
• Conocimiento general de los Procesos de Negocio, de los Servicios de TI ofrecidos por
la Vicepresidencia de Sistemas y Procesos de Entel y de los grupos de soporte
involucrados.
• Actitud de servicio orientada al Cliente.
Fecha: 18/09/2015
b. Objetivo del Rol
• Asegurar que el personal de soporte conoce y usa el proceso.

• Lograr que la Mesa de Servicio se convierta en el punto único de contacto para los
usuarios.
c. Responsabilidades de la Mesa de Servicio
• Llevar a cabo las actividades de Gestión de Incidentes con base en el proceso,

procedimientos e instrucciones de trabajo establecidos.
• Conocer el proceso, sus procedimientos e instrucciones de trabajo.
• Ser un verdadero punto único de contacto para la comunidad de usuarios.
• Ser el Soporte de Primer Nivel para los incidentes en aquellos casos que se
encuentren dentro de sus capacidades.
d. Actividades de la Mesa de Servicio
• Ejecutar las actividades en el día a día del proceso de Gestión de Incidentes.

• Proporcionar análisis iniciales de la Categorización y Priorización de los Incidentes
reportados.
• Informar a los usuarios del progreso en la resolución de los incidentes.
• Identificar oportunidades de mejora.
• Actualizar los registros de incidentes.
• Adquirir el conocimiento técnico y del negocio necesario para el desempeño de sus
actividades.
• Informar al equipo de trabajo los incidentes sucedidos y los que están siendo
atendidos, problemas y errores conocidos, por ejemplo: si hay una falla masiva o
Incidente Mayor, todo el personal de la Mesa de Servicios debe estar enterado.
• Cuidar que en la resolución de incidentes registrados se cumplan los objetivos de
Niveles de Servicio.
• Llevar a cabo el escalamiento a las diferentes Torres conforme se requiera.
• De ser necesario, escalar los incidentes con el Administrador de Incidentes
• Mantener la propiedad del Incidente (como miembro de la Mesa de Servicios)
aunque el Incidente se haya asignado a otra Torre.
• Confirmar con el usuario la solución y cerrar el Incidente.
• Registrar los Incidentes y proporcionar el soporte inicial a nivel básico.
4.1.4. Personal de Soporte de Segundo Nivel
a. Perfil del Rol
• Recomendable tener certificación en Gestión de Servicios de TI (Fundamentos) y

certificaciones intermedias en Operation Support and Analysis.
Fecha: 18/09/2015
• Alto nivel técnico y experiencia en soporte específico relacionado con el área de

conocimiento del cuál sea responsable.
• Manejo de herramientas para gestionar incidentes en su ámbito tecnológico.
• Gestión del tiempo.
• Capacidad de trabajar bajo presión.
• Excelente comunicación.
• Habilidades de documentación.
• Trabajo en equipo.
• Recomendable tener certificaciones de TI específicas al ambiente tecnológico
b. Objetivo del Rol
• Proporciona el soporte referente a los componentes de la Infraestructura de TI a

nivel especialista en alguno de los siguientes dominios tecnológicos:
• Aplicaciones de Negocio.
• Telecomunicaciones.
• Cómputo Central.
• Soporte en Sitio.
• Seguridad.
• Asegurar que los incidentes asignados sean resueltos.
c. Responsabilidades del Personal de Soporte de Segundo Nivel
• Conocer el proceso, sus procedimientos e instrucciones de trabajo.

• Utilizar los procedimientos e instrucciones de trabajo definidas para el proceso.
• Resolver los incidentes que le sean asignados.
d. Actividades del Personal de Soporte de Segundo Nivel
• Emplear los procedimientos e instrucciones de trabajo del proceso de Gestión de

Incidentes.
• Actualizar los registros de incidentes.
• Adquirir los conocimientos técnicos y del negocio necesarios para el desempeño de
sus actividades.
• Cuidar que en la resolución de incidentes registrados se cumplan los objetivos de
Niveles de Servicio acordados.
• Identificar, generar y actualizar Soluciones Temporales
• Generar las Solicitudes de Cambio (RFC’s) para la solución a los Incidentes cuando sea
necesario.
• Proporcionar soluciones dentro de un tiempo determinado e informar a los Usuarios
a través de la Mesa de Servicio el estatus de las mismas. Si aplica notificar al grupo de
IT la existencia de incidentes de severidades 1, 2 y 3.
• Coordinar las actividades de varios grupos que estén investigando un Incidente a
nivel especialista cuando sea necesario
• Ejecutar servicios de soporte proactivos los cuales pueden resultar en una temprana
detección de Incidentes.
Fecha: 18/09/2015
• Proporcionar soluciones definitivas a Incidentes si está dentro de su alcance
4.1.5. Proveedor Externo
a. Objetivo del Rol
• Apoyar al Personal de Soporte de Segundo Nivel en el análisis y solución de los

Incidentes aprovechando el conocimiento especializado que se tiene sobre los
componentes que soporta.
b. Responsabilidades del Proveedor Externo
• Conocer el proceso.
• Utilizar los medios de comunicación adecuados para compartir el conocimiento y
brindar soporte a la organización.
• Resolver los incidentes que le sean asignados por el Soporte de Segundo Nivel.
c. Actividades del Proveedor Externo
• Emplear los procedimientos e instrucciones de trabajo del proceso, propios del

Proveedor Externo.
• Dar seguimiento hasta su conclusión a los Incidentes que sean escalados al Proveedor
Externo.
d. Autoridad del Proveedor Externo
• Prevenir Incidentes compartiendo Workarounds de los componentes que soporta el

Proveedor Externo.
• Informar los avances al Personal de Soporte de Segundo Nivel sobre los incidentes
escalados al Proveedor Externo.
• Utilizar técnicas demostradas para la resolución de Incidentes.
4.1.6. Usuario
a. Objetivo del Rol
• Proporciona información de entrada al proceso de Gestión de Incidentes.
b. Responsabilidades del Usuario
• Utilizar los medios de comunicación para reportar las fallas en los Servicios de
Sistemas y los componentes que los soportan.
• Proporcionar la información detallada que le solicite la Mesa de Servicio con el fin de
agilizar la atención del Incidente.
• Una vez que el registro del incidente sea resuelto, el usuario deberá probar y
confirmar la solución del mismo a su entera satisfacción.
Fecha: 18/09/2015
• Apoyarse en la Mesa de Ayuda como punto único de contacto.

• Participar en las encuestas de satisfacción con respecto a la atención de los
Incidentes.
c. Actividades del Usuario
• Reportar todos los Incidentes tan pronto como sean identificados.

• Confirmar la solución de los Incidentes y recuperación de los Servicios de Sistemas.
5. CARACTERÍSTICAS
5.1. Estados del Ciclo de Vida del Incidente
A lo largo del Ciclo de Vida del Incidente, éste pasará por distintos estados dependiendo de la
fase en la que se encuentre. El estado del incidente refleja la posición en la que se encuentra
dentro de su ciclo de vida.
Debido a la importancia que se tiene al identificar todos los incidentes existentes en el estado en
que se encuentran para medir la eficiencia del proceso de Gestión de Incidentes, es importante
actualizar constantemente el estado que va adquiriendo el registro del incidente dentro de la
herramienta de Gestión de Servicios de Sistemas.
A continuación se muestran los distintos estados por los cuales pasará un incidente a lo largo de
su Ciclo de Vida:
No Estado Descripción
Desde el momento en que es abierto un nuevo
1 Open registro de incidente hasta el momento que se
asigna
Desde que alguno de los diferentes niveles de
2 Work in progress
atención inicia a trabajar en el incidente
Desde el momento que el especialista de TI
3 Pending customer asignado informa al usuario que se depende de
una acción de parte de él para finalizar el incidente
Cuando el especialista de TI asignado ha
4 Resolved
recuperado el servicio
Se cierra el Incidente al recibir el visto bueno del
5 Closed usuario o al transcurrir el tiempo máximo
prestablecido para su confirmación
Fecha: 18/09/2015
5.2. Categorización
El principal objetivo de la categorización es identificar y agrupar lógicamente los registros y

elementos de configuración por tipo, para que exista una coincidencia entre el proceso y la
infraestructura de tecnología que permita su adecuada atención y asegurar la mejor integración
de datos consistentes, precisos y significativos para la gestión de la información.
El modelo de categorización para ENTEL consta de tres niveles para realizar la clasificación:
• Nivel 1: Tipo de Servicio

Este nivel describe la categoría general del incidente que diferencia el tipo de servicio
de negocio, de infraestructura, etc.
• Nivel 2: Nombre del Servicio

Este nivel describe el servicio de negocio o el nivel de infraestructura afectado.
• Nivel 3: Componente
Este nivel describe el componente o elemento de configuración que presenta la falla.
En este campo, los componentes se pueden diferenciar con elementos genéricos o
particulares como aplicaciones, servidores, etc.
5.3. Priorización
Uno de los aspectos más importantes del manejo de Incidentes es definir su Prioridad. La
responsabilidad de esta definición recae en el proceso de Gestión de Niveles de Servicio dentro
de los parámetros establecidos en los Acuerdos de Nivel de Servicio (SLAs). La Organización debe
ser capaz de asignar la Prioridad a cada registro de Incidentes que sea abierto. La Prioridad se
define como una función del Impacto sobre el Negocio y de la Urgencia para la resolución.
Impacto
Critica Alto Medio Bajo
1 2 3 4
Critica
1 2 2 3
1
Alta
Urgencia
2 2 3 3
2
Media
2 3 3 4
3
Baja
3 3 4 4
4
5.3.1. Prioridad 1 – Crítica

Incidente de alto impacto en las funciones críticas del negocio por indisponibilidad o
degradación excesiva de desempeño en las aplicaciones y servicios que impidan la
Fecha: 18/09/2015
operatividad de los mismos y requiera de una solución inmediata. Impacta en todas las
operaciones y no existe un plan alternativo de solución (Workaround).
5.3.2. Prioridad 2 – Alta

Incidente de impacto significativo en alguna de las funciones del negocio por afectación
parcial en la disponibilidad o degradación del desempeño de las aplicaciones y s ervicios que
afecta a las operaciones bajo un escenario determinado. El incidente está controlado dado
que existe un plan alternativo de solución (Workaround) y los usuarios pueden esperar la
solución definitiva, la cual debe estar programada y ser inmediata.
5.3.3. Prioridad 3 – Media

Incidente de impacto moderado en alguna de las funciones del negocio por degradación leve
en el desempeño de las aplicaciones y servicios que afecta a una cantidad reducida de
operaciones, usuarios o clientes (menor al 10%) bajo un escenario determinado o es de poca
visibilidad para el negocio. Existe un plan alternativo de solución (Workaround) o se puede
esperar a la solución definitiva.
El riesgo inminente de que ocurra un incidente de impacto alto o crítico se debe considerar
como severidad 3.
5.3.4. Prioridad 4 – Baja

Incidente de bajo impacto en las funciones NO críticas del negocio que afecta a un solo
usuario, el usuario puede esperar a una fecha determinada para la solución definitiva. El
usuario de negocio puede continuar con sus tareas críticas de la operación. Se mantiene la
funcionalidad y el desempeño de las aplicaciones y/o servicios.
5.4. Criterios que deberá cumplir un Incidente Mayor
Los criterios que deberá cumplir un Incidente Mayor principalmente se definen con un enfoque
de Negocio, pero también pudieran incluir aspectos de Tecnología. Los criterios son:
• Todos los incidentes mayores serán administrados por un encargado cuya labor será
coordinar con las áreas responsables para el restablecimiento del servicio afectado. Es te
debe aplicar escalamiento en cualquier amenaza de incumplimiento en los SLA´s
establecidos, también notificará e integrará a todos los involucrados cuando el incidente
mayor se presente.
• El único que puede declarar/catalogar un incidente mayor es el Gestor de Incidentes de
ENTEL con el diagnóstico previo de los especialistas según el servicio afectado. Una vez
declarado Incidente Mayor el Gestor de Incidentes deberá informar a la Gerencia de
Operaciones y éste a su vez a la Dirección (en caso de que aplique).
• El equipo que detecta (o es informado) el incidente deberá notificar el incidente a toda la
vicepresidencia, indicando prioridad, hora de inicio, impacto en el negocio. Deberá
utilizar la lista de distribución: sistemas.alertas@entel.pe
• El Gestor de Incidentes es el responsable de notificar a los usuarios, para lo cual utiliz ará
la lista de distribución: FallaServiciosTI.Usuarios@entel.pe
Fecha: 18/09/2015
*Las notificaciones se realizarán vía telefónica cada 20 minutos a partir de la hora de captura del incidente que
generó el Incidente Mayor
5.4.1. Comunicación con Otras Vicepresidencias
La atención de un incidente puede requerir el apoyo o coordinación de la VP de Redes

para lo cual se ha establecido el siguiente canal de comunicación:
• Si se requiere comunicar a la VP de Redes la atención o apoyo de un incidente

se realizará a través de la cuenta noc.informa@entel.pe
• Si Redes requiere comunicar a la VP de S&P la existencia de un incidente se
realizará a través de la cuenta FallaServiciosTI.Usuarios@entel.pe
Todos los incidentes son comunicados a la VP de Redes a través del canal de

comunicación establecido, de la misma forma, los incidentes de la VP de Redes, son
comunicados a la VP de S&P utilizando los medios de comunicación establecidos.
5.5. Escalamiento
El objetivo principal del Modelo de Escalamiento es contar con una guía clara sobre el manejo de
los Incidentes para garantizar que las acciones tomadas relacionadas con el escalamiento de los
mismos estén alineadas con el cumplimiento de las necesidades del Negocio. Ocurre cuando se
involucra a personal de mayor autoridad y/o experiencia, en el momento que un Incidente o
Problema no puede ser solucionado dentro del tiempo acordado. Existen dos tipos de
escalamiento: Jerárquico y Funcional.
El fin es poder realizar un escalamiento adecuado y oportuno, alineado a los Acuerdos de Niveles
de servicio (SLAs) que se tienen negociados y tomando como referencia los principales Servicios
de Sistemas que soportan la operación del Negocio. Para ello, se definen las siguientes matrices
para acotar los niveles hacia los cuales se escalarán los Incidentes tanto funcional como
jerárquicamente.
5.5.1. Escalamiento Funcional
Tan pronto como se identifique que un Nivel de Soporte no sea capaz de resolver el Incidente
o cuando los tiempos acordados para resolución se han superado (lo que ocurra primero) el
incidente debe ser escalado inmediatamente al siguiente nivel de soporte.
5.5.2. Escalamiento Jerárquico
Si los incidentes han rebasado los tiempos asignados, y/o requieren aprobaciones o recursos
adicionales, algunos grupos de Directores, Gerentes o Coordinadores deberán ser
notificados. El escalamiento jerárquico debe continuar la cadena de autoridad definida en la
siguiente matriz con el fin de que las personas con mayor poder de decisión y/o los niveles
directivos estén informados para que puedan prepararse y tomar las medidas
correspondientes y/o decisiones necesarias.
Fecha: 18/09/2015
6. POLÍTICAS GENERALES
Las políticas generales para la Gestión de Incidentes representan las decisiones tomadas por
Entel Perú y el dueño del proceso de la Gestión de Incidentes, para la ejecución y administración
de las actividades punta a punta de dicho proceso. Todas las tecnologías y personal definido en el
alcance de la Gestión de Incidentes para los Servicios de TI deberán adherirse a estas políticas.
Estas políticas están diseñados para asegurar que todos los proveedores estratégicos de servicio
(internos y externos) trabajen de manera conjunta para cumplir satisfactoriamente con los
objetivos del proceso de Gestión de Incidentes de Entel Perú. Los lineamientos requeridos para
soportar las regulaciones externas y/o los requerimientos de sus clientes también están
incluidos.
Los lineamientos generales para la Gestión de Incidentes le pertenecen y son monitoreados por
el Dueño del proceso de la Gestión de Incidentes. El dueño del Proceso proveerá información
gerencial a los altos y medios ejecutivos para demostrar la eficiencia y eficacia de este proceso, el
cumplimiento a nivel organizacional y cumplimiento a un nivel individual y de departamento.
Este también es el responsable final de asegurar que las políticas globales agregan valor a la
organización y son revisadas y actualizadas por lo menos una vez al año.
La siguiente tabla provee un listado de mejores prácticas en las políticas globales de proces o para
la Gestión de Incidentes. Esto debe de ser discutido o modificado (si es necesario) y acordado
entre el dueño del proceso de la Gestión de Incidentes y la Vicepresidencia de Sistemas y
Procesos de Entel Perú. El administrador de Incidentes es el responsable final para asegurar el
cumplimiento de todas las políticas. En esta posición, el administrador de Incidentes debe de
tener la autoridad para asegurarse que los mandos medios mantienen a sus equipos como
responsables para una ejecución eficiente y efectiva de las actividades de la gestión de
Incidentes.
Declaración de la política Razón de la política Beneficios
La única manera en la que se Asegurar consistencia y • Consistencia en la Gestión de

administrarán los Incidentes administración con excelente Incidentes para todos los
relacionados con los Servicios calidad de los Incidentes desde usuarios.
publicados de la su detección hasta su • Consistencia en las políticas y
Vicepresidencia de Sistemas y resolución y cierre. los procedimientos cuando los
Procesos de Entel Perú será a Incidentes son escalados.
través del proceso de Gestión • Recuperación más rápida de
de Incidentes basado en ITIL. los Servicios.
• Mejora en la comunicación y
satisfacción con el cliente.
• Mejora en la administración de
la información.
El dueño del Proceso es el Proveer un punto único de • Asegura un punto único de
responsable final de todo este responsabilidad para el responsabilidad del proceso.
proceso y tiene la autoridad proceso de Gestión de
Fecha: 18/09/2015
para desarrollar políticas y Incidentes a lo largo de todas

procedimientos relacionados al las áreas tecnológicas de la VP
proceso. de S & P.
La Gestión de Incidentes Asegurar la consistencia en la • Provee un entendimiento claro
proveerá una definición única Gestión de los Incidentes. de lo que es un Incidente y
de Incidente, y de todos los todos aquellos términos
términos incluidos en dicho necesarios para su correcta
proceso, el cuál será utilizado ejecución.
de manera común a través de
todas las Torres involucradas
en los Servicios de la VP de S &
P
La Gestión de Incidentes tiene Definir el alcance del proceso • La Mesa de Servicio soportará
la responsabilidad de soportar de Gestión de Incidentes. única y exclusivamente los CI’s
solo el software, hardware y considerados como parte de
documentación que ha sido los Servicios proporcionados
definida como necesaria para por la VP de S & P y los
proporcionar los Servicios de la Servicios autorizados evitando
VP de S & P destinar recursos para
Servicios no autorizados.
Todos los Incidentes, Asegurar que todos los • Registro consistente y rastreo
independientemente de donde Incidentes y las Solicitudes de de todos los Incidentes.
sean detectados, serán Servicio sean registrados, • El rendimiento del entorno
registrados y actualizados actualizados y cerrados en la tecnológico puede ser medido
solamente en una herramienta. herramienta. de manera más precisa.
• Elimina el costo de
herramientas redundantes.
La Mesa de Servicio será el Para asegurar que todos los • Permite la aplicación de un
primer punto de contacto para Incidentes son administrados repositorio centralizado de
todos los usuarios. de manera consistente y de datos para Incidentes y un
manera centralizada a través punto de entrada consistente
de un solo punto. para la iniciación de las
actividades del proceso.
Todos los Incidentes serán Para administrar de manera • Los Incidentes Críticos serán
priorizados con base en el eficiente los Incidentes identificados de manera más
Impacto y la Urgencia definidos considerando las prioridades rápida.
en el modelo de prioridades. de Entel. • La velocidad y los recursos
necesarios para resolver un
Incidente serán asignados de
mejor manera.
En el caso en el que la Mesa de Asegurar que todos los • Los Incidentes se resuelven lo
Servicio o cualquier otro nivel Incidentes se manejan de más pronto posible.
de soporte excedan su manera eficiente y que son
capacidad de resolver un administrados por el grupo o
Incidente particular, el persona correcta.
Fecha: 18/09/2015
Incidente será escalado al

grupo o persona apropiada o
nivel ‘N’ de soporte funcional.
Todo el progreso en la Para asegurar actualizaciones • Información precisa y
resolución de los Incidentes, precisas y en tiempo para actualizada para proveérsela a
independientemente del nivel registrar los Incidentes y los usuarios en cualquier
de soporte o personal de TI de mantener el ciclo de vida o momento.
la VP de S & P, estará historial de los mismos.
claramente documentado en el
sistema de la Mesa de Servicios
de manera puntual.
El estado de los Incidentes Notificar a los clientes de los • Incrementar la satisfacción del
deberá estar disponible para avances en la resolución de los cliente.
los usuarios en todo momento Incidentes. • Reducir el volumen de
a través del ciclo de vida de los llamadas de seguimiento a la
mismos. Mesa de Servicio
La Mesa de Servicio será el Administrar de manera • Asegurar que todos los

dueño del ciclo de vida de eficiente los Incidentes. Incidentes reciben el soporte
todos los Incidentes. Todas las apropiado y en tiempo,
actividades asociadas con el independientemente de qué
Incidente son responsabilidad grupo o persona lo esté
de los grupos o personas atendiendo.
involucradas en la resolución
del mismo.
Se establecerán canales de Asegurar que Entel Perú tiene • Las expectativas del cliente se
comunicación con el personal una amplia conciencia respecto establecerán de manera
de VP de S & P y los posibles a cualquier Incidente que precisa.
usuarios afectados ante pudiera impactar los Servicios. • Reducir llamadas solicitando
cualquier degradación soporte, ya que los clientes
esperada o ante un impacto saben qué está sucediendo.
imprevisto a los Servicios de TI. • Incrementar la satisfacción del
cliente y la imagen de la VP de
S& P
La Gestión de Incidentes Asegurar que los Incidentes se • Cerrar en tiempo los
proveerá un lineamiento de resuelven de acuerdo con los Incidentes.
escalamiento de acuerdo con requerimientos de Entel Perú y • Incrementar la satisfacción del
las necesidades de Entel Perú asegurar que los niveles de usuario.
para asegurar que los servicio se mantienen. • Incrementar el entendimiento
Incidentes se administran en del personal de las Torres así
tiempo y forma. como sus roles y
responsabilidades.
• Asegurar que los niveles
apropiados de Gestión serán
notificados respecto al estado
de los Incidentes.
Fecha: 18/09/2015
El cierre del Incidente será el Asegurar que todas las • Mejora en el registro de la
resultado de la validación del soluciones definitivas o información relacionada con el
usuario confirmando que la temporales de los Incidentes cierre de los Incidentes.
resolución del Incidente se ha se llevan a cabo de acuerdo a • Incremento en la satisfacción
llevado a cabo y que el Servicio los SLA’s. del cliente.
efectivamente se ha restaurado • Reduce el volumen de llamadas
de manera satisfactoria o que a la Mesa de Servicio por haber
la Solución Temporal le permite asumido que el Incidente se
continuar con sus labores. había solucionado.
• El beneficio por completo se
podrá obtener si y solo si se
tienen definidos los niveles del
servicio en el SLA
Las métricas de la Gestión de Evaluar las métricas de • Proveer un análisis de
Incidentes y los reportes serán desempeño del proceso de tendencias para el proceso de
entregados a VP de S & P y Gestión de Incidentes. Gestión de Incidentes y su
usuarios de acuerdo con los manejo.
procedimientos acordados y • Identificar oportunidades de
definidos por Entel. mejora.
Las revisiones al proceso serán Maximizar los beneficios del • Identificar oportunidades de
elaboradas por el líder del proceso y minimizar los costos mejora para el proceso,
mismo de manera regular, a la vez que se mantiene herramientas y habilidades del
conforme se crea necesario. actualizado. personal.
Las revisiones se enfocarán en • Identificar necesidades de
la consistencia y efectividad del capacitación del personal
proceso. respecto al proceso y las
herramientas.
Fecha: 18/09/2015
7. DESARROLLO DEL PROCESO
7.1. Flujo de Alto Nivel del Proceso
7.0 Monitoreo, Registro, Comunicación y Administración de la información
7.2. Descripción de las Actividades del Proceso de la Gestión de Incidentes
Actividad Descripción
Fecha: 18/09/2015
1.0 Los detalles del Incidente ingresados en la Mesa de Servicio son las entradas de la Gestión de
Registro, Incidentes. Las acciones que resultan de esto son:
Categorización y • Registrar información básica del Incidente.
Priorización • Registrar información del usuario.
• Asignar identificador único al Incidente.
• Categorizar el Incidente con base en la tabla de Categorización y sus Elementos de
Configuración (CIs).
• Priorizar el Incidente.
Considerando la visión de la Vicepresidencia de Sistemas y Procesos de ENTEL Perú, no es

aceptable el esperar hasta que un usuario se vea impactado y éste contacte a la Mesa de
Servicio. Dentro de lo posible, todos los componentes críticos que soporten un Servicio de la
VP de S & P deberán ser monitoreados para detectar cualquier falla potencial.
Todos los Incidentes deben ser registrados sin excepción.
El monitoreo a la infraestructura tecnológica contribuye considerablemente en la generación

automática de incidentes.
2.0 Los registros de los Incidentes generados en la actividad previa, son analizados para des cubrir
Soporte Inicial posibles soluciones del Incidente. Las acciones como resultado de esto son:
• Relacionarlos con posibles Soluciones Temporales (“Workarounds”), si aplica.
• Analizar los detalles de configuración relacionados.
• Proporcionar el Soporte Inicial, en caso de aplicar.
El diagnóstico inicial podría dar como resultado la ejecución de la actividad de resolución del
Incidente por parte de la Mesa de Servicio. Esta resolución se puede derivar de diferentes
actividades como lo son:
• La identificación de un Error Conocido.
• Experiencia del personal de la Mesa de Servicio
• Búsqueda en las herramientas de conocimiento.
• Scripts de diagnóstico.
En caso necesario que el incidente se reporte a la Mesa de Servicios de ENTEL Chile (ejemplo),
el agente será responsable de registrar el incidente en la herramienta determinada, ser
intermediario entre el usuario y del seguimiento correspondiente hasta su solución y cierre.
Adicionalmente, la mesa de servicio debe levantar un incidente en la herramienta local para
fines estadísticos. Dicho incidente debe ser cerrado por el agente de la mesa de ayuda una vez
que haya sido resuelto.
Fecha: 18/09/2015
3.0 Durante la Investigación y el Diagnóstico, el Soporte de Segundo Nivel profundiza en el Incidente
Investigación y para determinar soluciones y siguientes pasos.
Diagnóstico
La Investigación y Diagnóstico puede convertirse en un proceso iterativo, que inicia con un grupo
de especialistas seguido de la eliminación de una posible causa previa, que podría involucrar
diferentes grupos de soporte. Todo esto, demanda un acercamiento disciplinado y riguroso,
además del registro detallado de las acciones realizadas con los resultados corresp ondientes.
Todas las actividades que se lleven a cabo en la Investigación y Diagnóstico deberán estar
completamente documentadas en el registro de Incidentes con la finalidad de tener un detalle
preciso de las acciones que se llevaron a cabo.
La Investigación deberá incluir las siguientes actividades:

• Establecer exactamente qué fue lo que falló o fue visto por el usuario.
• Entender el orden cronológico de los eventos.
• Confirmar el impacto completo del Incidente, incluyendo el número de usuarios afectados.
• Identificar cualquier evento que pudiera haber disparado el Incidente.
Las acciones como resultado de esto son:

• Análisis del detalle de los Incidentes.
• Colección y análisis de toda la información relacionada y la solución (incluyendo cualquier
“Workaround”)
• Escalarlo al siguiente nivel de soporte en caso de ser necesario
• Si es que se requiere el Soporte del Proveedor, se analizan las condiciones del mismo.
Siempre que sea posible, se le debe proporcionar al usuario los medios para continuar con sus
actividades, inclusive a través de un Servicio degradado.
Una vez que el Incidente ha sido asignado a un grupo o persona de alguna Torre, este deberá:
• Aceptar o rechazar la asignación del Incidente especificando la fecha y la hora además de
asegurar que:
o El estado del Incidente se mantenga actualizado.
o El historial de actividades del Incidente se actualice constantemente.
o El usuario vía el Service Desk se mantenga informado del progreso de la
resolución.
Fecha: 18/09/2015
4.0 Una vez identificada la solución, la Recuperación del Servicio puede ser efectuada y las
Solución y acciones de Recuperación realizadas por los especialistas o personal de soporte de un
Recuperación Proveedor designado para tales efectos. Se deberán registrar los estados y acciones durante
esta actividad.
Cuando se ha identificado una resolución potencial, esta debe ser aplicada y probada con la
finalidad de asegurar que la acción de recuperación se ha completado y que el estado normal
del Servicio se ha restaurado. Las acciones específicas a llevarse a cabo y las personas que
estarán involucradas en tomar las acciones de recuperación pueden variar dependiendo de la
naturaleza de la falla, y pueden incluir:
• Pedirle a un usuario el llevar a cabo actividades en su propio equipo.
• La Mesa de Servicio o Torres implementarán la resolución ya sea de manera
centralizada (por ejemplo al reiniciar un servidor) o de manera remota.
• Solicitar a grupos especialistas el implementar acciones específicas de recuperación.
• Solicitar a un proveedor externo el solucionar alguna falla.
• Asignar la categoría de Pending Change cuando requiera algún cambio
• Asignar la categoría de ‘Resuelto’ al Incidente.

• Resolver el Incidente usando la solución permanente o temporal (“Workaround”).
• Generar una Solicitud de Cambio (RFC) cuando el caso lo requiera.
• Documentar acciones para la Recuperación.
• Recuperar el servicio.
Fecha: 18/09/2015
5.0 Cuando el incidente ha sido solucionado, el usuario deberá ser informado por la Mesa de
Validación y Servicios (o el analista de segundo nivel responsable) para que pruebe y confirme la
Comunicación resolución aplicada:
• Los detalles de la resolución aplicada para resolver el Incidente deben ser claros para que
puedan utilizarse como conocimiento para posibles Incidentes similares.
• Todos los detalles aplicables a esta fase del control del Incidente son registrados,
indicando:
o Que el usuario fue informado.
o Que el usuario probó y confirmó su satisfacción con la resolución aplicada.

• Informar la resolución al Usuario o el generador del Incidente.
• Envío de las notificaciones de "sistemas alertas" cuando corresponda. Para los incidentes
de severidad 1, 2 y 3 se deberá usar el aplicativo de envío de notificación "Sistemas
alertas"
Cuando la solución del incidente ha sido aprobada por el usuario, el agente de la Mesa de
Servicios (o el analista de segundo nivel responsable) deberá validar la entera satisfacción del
usuario con respecto a las acciones realizadas para restablecer el Servicio:
• Los detalles de la validación con el usuario serán asentados en el registro del Incidente.

• Registrar el nivel de satisfacción del usuario.
• Comunicar la recuperación del Incidente a los interesados y el avance de las acciones para
Severidad 1,2 y 3.
Fecha: 18/09/2015
6.0 Cuando la solución del incidente ha sido validada, la Mesa de Servicios (o el analista de
Cierre segundo nivel responsable) se deberá asegurar que:
• Los detalles de las acciones realizadas para resolver el Incidente son precisas y
entendibles.
• La categorización es correcta y acertada de acuerdo a la solución, de ser necesario se
deberá corregir.
• La solución/acción fue acordada con el Cliente – siempre con un soporte documental, de
manera escrita o por correo electrónico.
• Todos los detalles aplicables a esta fase del control del Incidente son registrados,
indicando:
o Satisfacción del cliente.
o El tiempo de vida del incidente, desde su registro hasta su solución.
o La persona, fecha y hora de cierre.
Las acciones como resultado de esto son :
• Documentar el Incidente con cualquier detalle sobresaliente para asegurar una
completa documentación.
• Si es un Incidente recurrente, informar al responsable de Gestión de Problemas
• El cierre del incidente.
•
7.0 La Mesa de Servicios es responsable de adueñarse y supervisar la resolución de todos los
Monitoreo, Incidentes sin importar la fuente inicial ni la Torre que solucionará, siguiendo las actividades
Registro, que a continuación se mencionan:
• Monitorear regularmente el estado, el progreso de la solución y los Niveles de Servicio de
Comunicación y
los Incidentes abiertos.
Administración
de la • Consultar con el Administrador del Proceso de Incidentes cuando exista incertidumbre en
información la asignación del grupo de soporte, cuando el incidente se mueve entre diferentes grupos
especialistas.
• Dar prioridad al monitoreo de Incidentes de alto impacto.
• Mantener informado sobre el progreso a los Usuarios afectados.
• Buscar Incidentes similares.

• Monitoreo de los Incidentes.
• Escalar los Incidentes.
• Informar a los Usuarios.
En el caso en que un Incidente no logre alcanzar un progreso satisfactorio, la Mesa de Servicios

deberá actuar de acuerdo con los procedimientos de escalamiento funcional y/o jerárquico
previamente definidos. Estos procedimientos deben estar acordados con todos los grupos de
soporte de las diferentes Torres.
Fecha: 18/09/2015
7.3. Flujo detallado de las actividades
1.1 Identificar El usuario identifica que existe una falla en la operación o interrupción en el
Incidente servicio que está utilizando.
1.2 ¿Comunicación De acuerdo al tipo de usuario se identificará si debe llamar a la Mesa de
directa a la Mesa de Servicios. En caso afirmativo se procede a la actividad 1.3, en caso negativo se
procede a la actividad 1.4.
Servicio?
1.3 Reportar El usuario debe reportar el incidente y comunicar los detalles de cómo se
Incidente presentó la falla.
identificado
Fecha: 18/09/2015
1.4 Reporta en En caso que el usuario cuente con acceso a la herramienta de ITSM, éste debe
autoservicio generar el incidente y detallar el cómo se presentó el incidente.
1.5 Revisar reportes La Mesa de Servicios se encarga de revisar los incidentes que hayan sido
de autoservicio generados por usuarios con permisos en la herramienta para validar su
llenado e iniciar con el seguimiento.
1.6 Registrar Datos La Mesa de Servicios se encarga de registrar en la herramienta los datos
Generales del necesarios para tener identificado el incidente. Se asegura de documentar al
menos:
Incidente
• Servicio impactado
• Hora de falla
• Área de negocio afectada
1.7 Categorizar el La Mesa de Servicios con base en la información que obtiene del usuario
Incidente afectado identifica la categoría que debe tener el incidente.
El analista de incidentes (nivel I) documenta la categoría del registro,
considerando el elemento de configuración que se reporta con la falla. Ver
ejemplo en Anexo A.
1.8 ¿Es Solicitud de La Mesa de Servicios con base en la información que tienen por parte del
Servicio? usuario identifica si se trata de un incidente (falla en un servicio) o es un
requerimiento (solicitud de servicio) y de acuerdo a lo identificado sigue el
procedimiento de Solicitudes de Servicio o continúa con la información de un
incidente a la actividad 1.9.
1.9 Priorizar el La Mesa de Servicios, con base en la tabla de impacto y urgencia identificará
incidente la prioridad que debe tener el incidente o la solicitud de servicio.
Ver Anexo B.
1.10 ¿Grupo de La Mesa de Servicios identifica a partir de los datos del incidente si éste debe
soporte interno? ser atendido para su solución por un grupo de soporte de Entel o deberá ser
atendido por los proveedores locales.
1.11 Relacionar en la En caso de identificar que el incidente debe ser atendido por un grupo de
herramienta local el soporte de Entel, la Mesa de Servicios genera el incidente en la herramienta
incidente levantado local y registra la información.
1.12 ¿Es Incidente La Mesa de Servicios debe identificar si el incidente reportado, que involucre
Mayor? a los servicios soportados en forma local, debe declararse como incidente
mayor o no. Los criterios de Incidente Mayor se encuentran en la sección C de
este documento.
En caso afirmativo se procede a la actividad 1.13, en caso negativo se
procede a la actividad 1.14.
1.13 Calificar como Con base en la información del incidente y el conocimiento previo de los
Incidente Mayor criterios para declarar un incidente mayor, la Mesa de Servicios realiza la
calificación de éste.
1.14 ¿Puede La Mesa de Servicios detecta si le es posible resolver el incidente. En caso
Resolver Incidente? afirmativo se procede a la actividad 2.1, en caso negativo se procede a la
actividad 2.8.
Fecha: 18/09/2015
2.1 Acceder a La Mesa de Servicios cuenta con acceso a documentación de errores
información de anteriores ya solucionados para apoyarse en la resolución del incidente
Gestión de actual.
Incidentes y Errores
Conocidos
2.2 Verificar La Mesa de Servicios analizará en la documentación de errores conocidos si
existencia de existe una referencia o similitud con el incidente que se está presentando en
la operación para solucionar de forma más ágil la falla.
Solución Temporal
2.3 ¿Solución La Mesa de Servicios detecta si es posible aplicar alguna solución a partir de la
relacionada? información de incidentes similares con la solución documentada. En caso
afirmativo se procede a la actividad 2.4, en caso negativo se procede a la
actividad 2.5.
2.4 Aplicar solución En caso de haber encontrado documentada la solución de un incidente similar
relacionada en la base de errores conocidos, la Mesa de Servicios se encargará de aplicar
la solución.
2.5 Aplicar nuevas Si la Mesa de Servicios no encuentra información relacionada con un incidente
acciones de solución similar al que está ocurriendo en el momento, se encargará de aplicar la
Fecha: 18/09/2015
solución que considere necesaria para restaurar el servicio.

2.6 ¿Se soluciona Al aplicar la solución, la Mesa de Servicios identificará si le fue posible
Incidente? recuperar el servicio para el usuario. En caso afirmativo se procede a la
actividad 2.7, en caso negativo se procede a la actividad 2.8.
2.7 Cambiar a En caso de que la Mesa de Servicios logre resolver el incidente, debe
Resuelto el actualizar la información en el registro del mismo en la herramienta y cambiar
el estado de éste indicando que ya está solucionado. Es necesario actualizar la
incidente y
base de Información de Gestión de Incidentes y errores conocidos.
actualizar
información
2.8 Asignar el Cuando a la Mesa de Servicios no le sea posible solucionar el incidente, debe
incidente a Segundo buscar que el grupo de soporte adecuado se encargue de encontrar la
solución.
Nivel
En caso de que un SLA se vaya a incumplir, deberá haber un escalamiento
jerárquico, de acuerdo a lo descrito en los lineamientos de Niveles de Servicio.
Fecha: 18/09/2015
3.1 Revisar El Grupo de Soporte de segundo nivel al tener asignado el incidente, iniciará
información con el análisis para conocer el detalle de la falla que se le está presentando al
usuario.
3.2 Analizar El Grupo de Soporte de segundo nivel, con base en análisis realizado,
incidente y plantear determina los pasos que debe realizar para encontrar la solución.
siguientes
actividades
3.3 ¿Requiere El Grupo de Soporte decidirá si es necesario algún tipo de apoyo externo por
Apoyo externo? la complejidad del incidente. En caso afirmativo, se procede a la actividad 3.4,
en caso negativo se procede a la actividad 4.1.
3.4 Verificar El Grupo de Soporte valida si se cuenta con un contrato con el proveedor que
condiciones de se necesita de apoyo para resolver el incidente y las condiciones del mismo.
apoyo con
proveedor
3.5 Gestionar El Grupo de Soporte de Segundo Nivel inicia el contacto con el proveedor
soporte Proveedor externo para que éste inicie la búsqueda de la solución.
Externo
3.6 Cambiar estado El incidente es actualizado por el Grupo de Soporte de Segundo Nivel para
a Asignado a indicar que el incidente lo tiene ahora asignado el proveedor externo (en la
herramienta el status es “Pending vendor”).
Proveedor Externo
3.7 Asignar El Grupo de Soporte de Segundo Nivel, dentro de la herramienta, asigna el
Incidente a incidente al proveedor externo y le notifica a éste que el tiempo de solución
comprometido empieza a correr.
Proveedor Externo
Fecha: 18/09/2015
4.1 ¿Se requiere un El Grupo de Soporte de Segundo Nivel identifica si para solucionar el incidente
Cambio? es necesario abrir un cambio. En caso afirmativo se debe interactuar con el
proceso de Gestión de Cambios.
4.2 Aplicar acciones El Grupo de Soporte de Segundo Nivel al identificar que no es necesario
de solución generar un cambio, inicia con las actividades que considera necesarias para
solucionar el incidente.
4.3 ¿Se soluciona? El Grupo de Soporte de Segundo Nivel valida si con las acciones realizadas, el
incidente se solucionó. En caso afirmativo se procede a la actividad 4.4, en
caso negativo se procede a la actividad 4.5.
4.4 Cambiar a En caso de que el Grupo de Soporte de Segundo Nivel solucionó la falla en el
Resuelto el servicio, actualiza el estado del incidente dentro de la herramienta,
incidente, actualiza documenta la forma en la cual detectó dónde estaba la falla y las acciones que
tomó para realizar la restauración. Una vez concretados estos pasos, notifica a
información e la Mesa de Servicios para cumplir con esta parte del proceso de Incidentes.
Informa a Mesa de
Fecha: 18/09/2015
Servicio
4.5 Actualiza En el caso de no resolver el Grupo de Soporte de Segundo Nivel el incidente,
información del éste debe documentar las acciones que aplicó en el intento de solucionarlo y
Incidente procede a buscar apoyo con proveedores externos.
4.6 Revisar El Grupo de Soporte de Segundo Nivel gestiona el soporte con el proveedor
información externo y éste revisa la información del incidente.
4.7 Analizar El proveedor externo se encarga de revisar y analizar la información sobre el
incidente y notifica incidente y con ésta encontrar la solución y dar a conocer al Grupo de Soporte
de Segundo Nivel, quien evalúa si hay necesidad de generar un cambio o no.
solución
Fecha: 18/09/2015
5.1 Informar al usuario La Mesa de Servicios, una vez que tiene la información por parte del Grupo
de la Solución de Soporte de Segundo Nivel de que se ha solucionado el incidente,
procede a notificar al usuario de ésta noticia.
5.2 Validar solución con La Mesa de Servicios solicita al usuario realice pruebas para validar que el
usuario servicio se encuentra restablecido.
5.3 Realizar pruebas y El Usuario inicia las pruebas de verificación para dar su visto bueno de que
confirmar solución todo funcione de forma normal.
5.4 Validar con Soporte La Mesa de Servicios se pone en contacto con el Grupo de Soporte de
Segundo Nivel si se Segundo Nivel para identificar si a partir del incidente debe ser generado
genera un Problema un problema.
6.1 ¿Es un Problema? Se toma la decisión de si es un problema o no, en caso afirmativo, se inicia
el proceso de Gestión de Problemas. En caso contrario, se procede a la
actividad 6.2.
6.2 Cerrar incidente y La Mesa de Servicios procede a cerrar el incidente y automáticamente se
enviar encuesta envía al Usuario una encuesta de satisfacción para cumplir con la medición
del servicio y satisfacción del cliente.
Fecha: 18/09/2015
8. MATRIZ RACI
La Matriz RACI define para cada actividad del proceso el nivel de compromiso que debe tener
cada uno de los roles involucrados. Los niveles de compromiso se definen en la siguiente tabla:
Administrador de
Mesa de Servicio
Soporte Segundo
Roles dentro del Proceso
Proveedor
Incidentes
Externo
Usuario
Nivel
Actividades del Proceso
1. Registro, Categorización y
R I
Priorización
2. Soporte inicial C R I
3. Investigación y Diagnóstico I I R C/I
4. Solución y Recuperación I I R R I
5. Validación y Comunicación I R R
6. Cierre I R I
El Dueño del Proceso se considera Accountable (A) para el presente proceso.
Nivel de Compromiso
A = Accountable Responsable Final
R = Responsible Responsable de la Ejecución
C = Consulted Consultado para Obtener más información acerca de la actividad
I = Informed Necesita estar Informado sobre las acciones tomadas acerca de la actividad
Fecha: 18/09/2015
9. FACTORES CRÍTICOS DE ÉXITO Y MONITOREO DE DESEMPEÑO
Evaluar el desempeño del proceso permite identificar su comportamiento y determinar si se están

alcanzando los objetivos para los cuales fueron creados. Así mismo, facilita la conjunción de
información estructurada con base en métricas y reportes, que será de valor para la toma de
decisiones, propiciando la ejecución de acuerdo a las circunstancias presentadas.
En este sentido, a continuación se definen dos elementos cruciales para la evaluación del desempeño
del Proceso de Gestión de Incidentes: Indicadores Clave de Desempeño (KPIs) y Reportes gerenciales
relevantes para verificar su cumplimiento.
9.1. Indicadores Clave de Desempeño (KPIs)
A continuación, se presentan los Indicadores Clave de Desempeño (KPIs) iniciales para el proceso
de Gestión de Incidentes. De igual forma, se presentan una serie de métricas que pueden ser
utilizadas para obtener dichos KPIs.
Indicador Clave de Desempeño Métricas que soportan los KPIs

% de incidentes resueltos a) Número total de incidentes registrados:
• General
% de incidentes que se solucionaron • Por Categoría
dentro de los tiempos establecidos • Por Tipo
• Por Prioridad
b) Número total de incidentes resueltos y cerrados:
• General
• Aplicando Workaround
• Dentro del tiempo establecido
c) Número total de incidentes resueltos por grupo
solucionador:
• Soporte Nivel 1 – Mesa de Servicio
• Soporte Nivel 2 – Soporte Segundo Nivel
• Soporte Nivel 3 – Proveedor Externo
a) Número de incidentes reasignados

b) Número de incidentes con solución documentada
c) Número de incidentes con categoría redefinida
d) Número total de incidentes registrados
e) Número de incidentes relacionados con cambios mal
ejecutados
El logro de los KPI’s debe de ser monitoreados y usados para identificar oportunidades de mejora,
que debería de ser incluido en el registro de CSI para su evaluación y posible implementación.
Fecha: 18/09/2015
9.2. Reportes
Para complementar la verificación del desempeño del proceso, es necesario generar los reportes
que sirvan de referencia para comprobar dicho desempeño. A continuación, se muestran los
reportes identificados. Es responsabilidad del Administrador del Proceso de Gestión de
Incidentes agregar o modificar reportes del proceso conforme éste vaya madurando.
Tipo de Reporte Frecuencia Dirigido a

• Número total de incidentes
P1: Semanal • Coordinadores y Jefes
pendientes por ser resueltos
• Número de total de incidentes
P1: Mensual • Coordinadores y Jefes
resueltos a tiempo
• Número total de incidentes cerrados P1: Mensual • Coordinadores y Jefes
9.3. Integración con otros procesos
La siguiente tabla describe los puntos básicos donde el Proceso de Gestión de Incidentes
interacciona con otros procesos, principalmente con Gestión de Problemas, Cambios y
Configuraciones. La columna “acciones” muestra las actividades o disparadores de un proceso a
otro. La columna “información” muestra los datos o salidas que son transferidas a los otros
procesos con el objetivo de que cuenten con información para toma de decisiones o para
generar reportes.
Proceso
Acciones Información
De Para
• Escalamiento de incidentes • Descripción e información de
sin solución. Incidentes abiertos sin
• Escalamientos de Incidentes solución.
Gestión de mayores. • Descripción e información de
Problemas • Escalamiento de incidentes Incidentes mayores abiertos.
que cumplen con los • Descripción e información de
criterios de Problemas. incidentes que llegan al
Gestión de proceso de Problemas.
Incidentes • Reporte de incidente • Información de los incidentes
Gestión de producto de cambios mal resultados de los cambios.
Cambios implementados.
Gestión de • Elementos de Configuración • Relación de Elementos de

Configuraciones (CIs) no incluidos en la Configuración (CIs) que no se
CMDB. encuentran incluidos en la
CMDB.
Fecha: 18/09/2015
Proceso
Acciones Información
De Para
Gestión de • Reporte de problemas • Notificación de los problemas
Problemas cerrados relacionados a cerrados relacionados a
incidentes escalados. incidentes escalados.
• Comparte Base de datos de • Información detallada de la
Errores Conocidos (KEs). solución aplicada a los
problemas escalados desde la
gestión de incidentes.
Gestión de
Gestión de • Comparte Calendario de • Notificación de los cambios
Incidentes
Cambios Cambios Autorizados. aprobados relacionados a
incidentes solicitados.
• Calendario de cambios
Autorizados y Planificados.
Gestión de • Comparte Base de Datos de • Detalle de los Elementos de
Configuraciones Gestión de Configuraciones Configuración (CIs) incluidos
actualizada. en la CMDB
Fecha: 18/09/2015
Fecha: 18/09/2015
10. ANEXOS
10.1. Grupos de Escalamiento
AP LICA CI ONES
Niveles de
Rol Área Nombre E-mail Teléfono
Escalamiento
SUPERVISOR DE CRM, ERP, PREPAGO,
Anexo 4664
OPERACIONES TI - APROVISIONAMIENT Mateo
1er Nivel mateo.rey@entel.pe Celular
APLICACIONES - O, DWH, Rey
998377033
DELIVERY REGULATORIOS
JEFE DE Anexo 2806
Fredy
2do Nivel OPERACIONES IT APLICACIONES TI fredy.silva@entel.pe Celular
Silva
DE APLICACIONES 970547950
Anexo 2614
GERENTE DE GERENCIA DE Cesar cesar.ramirez.a@entel.
3er Nivel Celular
OPERACIONES TI OPERACIONES TI Ramirez pe
977713447
IN FR AE ST R UC TU RA
Niveles de
Escalamiento
BASE DE DATOS
UNIX Anexo 2653

SUPERVISOR DE Eddy
eddy.reinoso@entel.pe Celular
SERVIDORES Reinoso
SISTEMAS WINDOWS 998102631
1er Nivel
MIDDLEWARE
SUPERVISOR DE SISTEMAS DE VOZ Anexo 2666

Ricardo ricardo.gonzales@entel.
REDES Y SISTEMAS Celular
Gonzales pe
DE VOZ REDES 947238128
JEFE DE Anexo 2608
Carlos carlos.posadas@entel.p
2do Nivel INFRAESTRUCTUR INFRAESTRUCTURA Celular
Posadas e
A TI 994001312
Anexo 2614
3er Nivel Celular
977713447
SEGURIDAD
Niveles de
Escalamiento
ADMINISTRADOR Anexo 2595
Orlando orlando.samanez@ente
1er Nivel DE ACCESO A SEGURIDAD TI Celular
Samanez l.pe
SISTEMAS 983453546
SUPERVISOR DE Anexo 2619
Rene
2do Nivel SEGURIDAD SEGURIDAD TI rene.perez@entel.pe Celular
Perez
INFORMÁTICA 947371051
Fecha: 18/09/2015
Anexo 2614
3er Nivel Celular
977713447
PRODUCCION
Niveles de
Escalamiento
Anexo 2573
SUPERVISOR DE CENTROS DE Ewen
1er Nivel ewen.juarez@entel.pe Celular
PRODUCCION TI CÓMPUTO Juarez
947110707
Anexo 2160
SUPERVISOR DE CENTROS DE Fernand fernando.chau@entel.p
2do Nivel Celular
PRODUCCION TI CÓMPUTO o Chau e
998102666
Anexo 2614
3er Nivel Celular
977713447
Tabla: Matriz de Escalamiento Jerárquico
11. REGISTROS
No aplica

Gestión de incidentes en Entel

Cargado por

Información del documento

Título original

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

Gestión de incidentes en Entel

Cargado por

Copyright:

Formatos disponibles

PROCESO DE GESTIÓN DE INCIDENTES

Fecha Descripción del Cambio Versión Responsable

18/02/2015 Versión Inicial 1.0 Max Pizarro

Actualización de la documentación en el Oscar Narváez

Nombre y Apellidos Cargo Fecha

Revisado por: Cesar Ramirez Gerente de Operaciones 18/09/2015

Los objetivos detallados del proceso de Gestión de Incidentes son:

• Reducir el tiempo destinado a la solución de los Incidentes.

El proceso de Gestión de Incidentes es el responsable de gestionar el ciclo de vida de todos los

• Incidente Normal: Cualquier evento que no es parte de la operación estándar de un servicio,

4.1. Roles del Proceso

• Dueño del proceso

4.1.1. Dueño del Proceso

a. Perfil del Rol

Tendrá la responsabilidad de principio a fin de asegurar que el Proceso de Gestión de

b. Responsabilidades del Dueño del Proceso de Incidentes

Las responsabilidades se dividen en los siguientes tres aspectos:

c. Actividades del Dueño del Proceso de Incidentes

4.1.2. Administrador de Incidentes

a. Perfil del Rol

El Administrador de Incidentes reporta al Dueño del Proceso de Incidentes y lleva a cabo

El Administrador de Incidentes es responsable de la identificación de oportunidades de

Finalmente, el Administrador de Incidentes es responsable de suministrar reportes a los

En general el perfil ideal para el Administrador de Incidentes es el siguiente:

b. Objetivo del Rol

• Responsable por la operación del día a día del proceso.

c. Responsabilidades del Administrador de Incidentes

Las responsabilidades se dividen en los siguientes tres aspectos:

d. Actividades del Administrador de Incidentes

Las actividades son las siguientes:

4.1.3. Ejecutivo de Primer Nivel (Mesa de Servicios)

a. Perfil del Rol

• Recomendable tener certificación en Gestión de Servicios de TI (fundamentos).

b. Objetivo del Rol

• Asegurar que el personal de soporte conoce y usa el proceso.

c. Responsabilidades de la Mesa de Servicio

• Llevar a cabo las actividades de Gestión de Incidentes con base en el proceso,

d. Actividades de la Mesa de Servicio

• Ejecutar las actividades en el día a día del proceso de Gestión de Incidentes.

4.1.4. Personal de Soporte de Segundo Nivel

a. Perfil del Rol

• Recomendable tener certificación en Gestión de Servicios de TI (Fundamentos) y

• Alto nivel técnico y experiencia en soporte específico relacionado con el área de

b. Objetivo del Rol

• Proporciona el soporte referente a los componentes de la Infraestructura de TI a

c. Responsabilidades del Personal de Soporte de Segundo Nivel

• Conocer el proceso, sus procedimientos e instrucciones de trabajo.

d. Actividades del Personal de Soporte de Segundo Nivel

• Emplear los procedimientos e instrucciones de trabajo del proceso de Gestión de

• Proporcionar soluciones definitivas a Incidentes si está dentro de su alcance

4.1.5. Proveedor Externo

a. Objetivo del Rol

• Apoyar al Personal de Soporte de Segundo Nivel en el análisis y solución de los

b. Responsabilidades del Proveedor Externo

c. Actividades del Proveedor Externo

• Emplear los procedimientos e instrucciones de trabajo del proceso, propios del

d. Autoridad del Proveedor Externo

• Prevenir Incidentes compartiendo Workarounds de los componentes que soporta el

a. Objetivo del Rol

• Proporciona información de entrada al proceso de Gestión de Incidentes.

b. Responsabilidades del Usuario

• Apoyarse en la Mesa de Ayuda como punto único de contacto.

c. Actividades del Usuario