BTO-PYM-GES-GUI-45429 Guia Operativa Servicios de Conectividad en CEx y CGE v1.8

Febrero 2023
Edición 1.8
ciaçioEso h
Entidad Emisora
TELEFÓNICA SOLUCIONES DE OUTSOURCING

S.A.U.
Título
GUÍA OPERATIVA SERVICIOS CONECTIVIDAD EN

CENTROS DE EXCELENCIA (CEx) Y DE GESTIÓN
ESPECIAL (CGE)
Código
BTO-PYM-GES-GUI-45429
Guía Operativa Servicios de Conectividad en Centros de Excelencia (CEx) y de Gestión Especial (CGE)
Contenido
NOVEDADES............................................................................................................................................................................... 4
1 OBJETO............................................................................................................................................................................... 5
2 UNIDADES AFECTADAS.................................................................................................................................................6
3 INTRODUCCIÓN...............................................................................................................................................................7
4 A1 - ATENCIÓN AL USUARIO......................................................................................................................................10
5 A3 - MONITORIZACIÓN DE EVENTOS DE LA EXPLOTACIÓN.............................................................................23
5.1 PARAMETRIZACIONES WOCU.........................................................................................................................27
5.1.1 SISTEMA DE CRÉDITOS COMPARTIDOS..............................................................................................32
5.2 CUADRO RESUMEN DE PARAMETRIZACIONES WOCU.............................................................................34
5.3 GESTION REACTIVA...........................................................................................................................................38
6 GESTIÓN DEL CICLO DE VIDA DE LAS INCIDENCIAS, PETICIONES, CONSULTAS Y RECLAMACIONES.49
6.1 A4 - REGISTRO......................................................................................................................................................49
6.1.1 PROCEDIMIENTO DE CONTINGENCIA GDIA Y SAC VANTIVE.......................................................69
6.1.2 INCIDENCIAS LOCALES...........................................................................................................................70
6.1.3 INCIDENCIAS ANULADAS.......................................................................................................................72
6.1.4 INCIDENCIAS MASIVAS...........................................................................................................................74
6.1.5 ACCESOS Y RESPALDOS MÓVILES VPN IP.........................................................................................75
6.1.6 INCIDENCIAS CON UN SEGUNDO OPERADOR (soluciones especiales).............................................75
6.1.7 INCIDENCIAS DEL SERVICIO CGE MULTIOPERADOR......................................................................76
6.2 A5 - DIAGNÓSTICO DE INCIDENCIAS.............................................................................................................76
6.2.1 ACCESOS Y RESPALDOS 3g/4g/5g (VPN IP + DATAINTERNET).......................................................79
6.3 A6 - TRANSFERENCIA........................................................................................................................................81
6.3.1 ACCESOS Y RESPALDOS 3G/4G/5G VPN IP + DATAINTERNET.......................................................83
6.3.2 INCIDENCIAS CON UN SEGUNDO OPERADOR...................................................................................87
6.3.3 GESTIÓN DE ACCESOS A CDG/TIC........................................................................................................87
6.4 A7 - INFORMACIÓN.............................................................................................................................................89
6.5 A8 - SEGUIMIENTO Y ESCALADO....................................................................................................................90
6.5.1 ASEGURAMIENTO DEL PROCESO DE RESOLUCIÓN DE INCIDENCIAS........................................90
6.5.2 INCIDENCIAS RECIBIDAS........................................................................................................................95
6.5.3 INCIDENCIAS SIN CONTACTO PRIMER DIAGNÓSTICO....................................................................95
6.5.4 INCIDENCIAS SIN SIRIO...........................................................................................................................95
6.5.5 INCIDENCIAS REPETIDAS.......................................................................................................................96
6.5.6 INCIDENCIAS DEVUELTAS.....................................................................................................................96
6.5.7 INCIDENCIAS DE MAS DE 24 HORAS....................................................................................................96
6.5.8 INCIDENCIAS DE MÁS DE 48 HORAS....................................................................................................96
6.6 A9 - RESOLUCIÓN................................................................................................................................................99
6.6.1 TABLAS DE RESOLUCIÓN/CIERRE POR SERVICIO............................................................................99
6.6.2 INCIDENCIAS CON CAUSA SOLUCIÓN/CIERRE “FALLO ELÉCTRICO / FALTA FLUIDO EN
DOMICILIO DE CLIENTE”.........................................................................................................................................112
6.6.3 INCIDENCIAS REPETIDAS.....................................................................................................................113
6.6.4 INCIDENCIAS MASIVAS.........................................................................................................................113
6.6.5 INCIDENCIAS CON UN SEGUNDO OPERADOR.................................................................................113
6.7 A10 - CONFIRMACIÓN DE CIERRE.................................................................................................................114
6.7.1 INCIDENCIAS CON UN SEGUNDO OPERADOR.................................................................................114
7 A11 - GESTIÓN DE PROBLEMAS...............................................................................................................................115
8 A12 - EJECUCIÓN DE OPERACIONES DE MANTENIMIENTO PREVENTIVO Y CORRECTIVO.....................116
8.1 SERVICIOS DE DATOS......................................................................................................................................118
8.2 SERVICIOS DE VOZ...........................................................................................................................................118
9 A13 - CAMBIOS DE CONFIGURACIÓN.....................................................................................................................119
10 A22 - CONTROL DE INVENTARIO.............................................................................................................................121
10.1 ACTUACIONES DE REGULARIZACIÓN ANTE BAJAS /PRE-BAJAS DE EQUIPOS................................124
10.1.1 RECOMENDACIONESDE ACTUACIÓN EN CEx (ESTANDAR) Y CEx AVANZADO.....................127
11 A23 - INVENTARIADO DE CONFIGURACIONES....................................................................................................128
12 A24 - REPORTING.........................................................................................................................................................130
12.1 HEALTH-CHECK DIARIO.................................................................................................................................130
Edición 1.8
NIVEL DE CONFIDENCIALIDAD: RESTRINGIDO. Queda prohibida cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación
pública y/o transformación, total o parcial, por cualquier medio, de este documento sin el previo consentimiento expreso y por escrito de Telefónica
Soluciones de Outsourcing S.A.U.
Página 2 de 155
13 ACTIVIDADES DE PROVISIÓN..................................................................................................................................135
13.1 A15 - ATENCIÓN A INSTALADORES..............................................................................................................136
13.2 A16 - COORDINACIÓN DE VENTANAS DE ACTUACIÓN..........................................................................136
13.3 A19 - CONFIGURACIÓN Y ACTIVACIÓN DEL SERVICIO..........................................................................137
13.3.1 PROVISIÓN RPV INTERNACIONAL......................................................................................................138
13.4 A20 - VALIDACIÓN DEL SERVICIO Y TESTEO............................................................................................138
14 DEROGACIONES Y EFECTIVIDAD...........................................................................................................................139
15 APROBACIÓN................................................................................................................................................................139
ANEXO 1: DEFINICIONES....................................................................................................................................................140
ANEXO 2: PLAN DE COMUNICACION A CLIENTE.........................................................................................................144
ANEXO 3: HISTÓRICO DE REVISIONES............................................................................................................................148
Edición 1.8
Página 3 de 155
NOVEDADES
La siguiente tabla muestra las novedades incorporadas en esta versión del documento.
Edición Fecha Observaciones - Modificaciones
Se sustituye el apartado Ediciones y Revisiones por los apartados Novedades e Histórico de

revisiones
Apartado 5.2: Se actualizan los packs de monitorización necesarios para Datainternet 5G.
Apartado 6.1: Se actualiza la tabla de CEx Premium y CGE con las nuevas vías de entrada y
recepción de la actividad.
Apartado 6.1: Se actualiza la tabla ASOCIACIÓN SERVICIOS - TIPO DE IDENTIFICATIVO.
Apartado 6.1: Se actualiza el flujo de tratamiento para tratamiento de incidencias “Fuera de
Horas” dependientes de CGEs “NO 7*24”.
Apartado 6.1.6: Se actualiza la operativa para registro de incidencias de Soluciones Especiales
1.8 15/02/2023 de accesos de un 2º Operador
Añadido apartado 6.1.7 Incidencias del servicio “CGE Multioperador”
Apartado 6.2.1: Se actualiza el alcance del apartado incluyendo al servicio Datainternet.
Apartado 6.3.1: Se actualiza el alcance del apartado incluyendo al servicio Datainternet.
Apartado 6.5.1: Se actualiza el buzón de escalado I + M (cambia de
escaladosim.serviciosempresas@telefonica.com a escalados.im@telefonica.com)
Apartado 6.6.1: Se matiza que el cierre “Cliente demora la atención de la incidencia” aplica solo
en el caso de incidencias locales y que la demora debe ser superior a 48 horas laborables.
Se actualizan/eliminan referencias a SAC/Vantive.
En los anexos se encuentra disponible el HISTÓRICO DE REVISIONES.
Edición 1.8
Página 4 de 155
1 OBJETO
El objeto de este documento es describir las instrucciones operativas asociadas a las actividades de
mantenimiento (correctivo y preventivo), y de provisión de los servicios de catálogo de datos y voz
integrados en los Centros de Gestión y Centros de Excelencia de Telefónica en sus distintas
modalidades de gestión.
Edición 1.8
Página 5 de 155
2 UNIDADES AFECTADAS
El contenido de este procedimiento afecta a las siguientes unidades de la Dirección General de
Operaciones:
- Dirección Postventa Empresas.

- Direcciones Territoriales de Operaciones.
Este procedimiento es de obligado cumplimiento en los servicios de Telefónica:
- CEx (Gestión estándar)

- CEx Avanzado
- CEx Premium
- CEx Premium Plus
- CGE (Proyecto especial)
- CGA (Descatalogado en proceso de finalización)
- CG Mixto (Descatalogado en proceso de finalización)
Edición 1.8
Página 6 de 155
3 INTRODUCCIÓN
Este documento incluye las instrucciones operativas generales asociadas a las actividades que se
deben realizar sobre los servicios de conectividad (datos y voz) integrados en los Centros de
Excelencia (CEx) o Centros de Gestión.
Esta información debe complementarse con las siguientes fuentes de información:
- Las instrucciones específicas incluidas en las guías de cada servicio ubicadas en la Biblioteca
Técnica Operativa (BTO). Como orientación sobre las guías aplicables en cada caso puede
consultarse:
Personal de TSO y Tempotel: Portal de gestión / Gestión catálogo / Actividades por elemento.
Personal de proveedor: a definir por el proveedor.
- Los manuales de los sistemas de gestión integrados, pudiendo consultarse su ubicación en

el Mapa de Sistemas:
Personal de TSO y Tempotel: Portal de gestión / Gestión catálogo / Mapa de sistemas.
Personal de proveedor: a definir por el proveedor.
- El Manual de marketing CEx/CGE ubicado en la Biblioteca Técnica Operativa (BTO).
- Los procedimientos complementarios e información específica existente en algunos

clientes, consultables en ATEx.
La gestión de los servicios, actividades o sistemas no integrados deberá ser validada mediante
Validación Técnica Operativa (VTO) que recoja las instrucciones específicas de gestión en cada caso.
A continuación, se muestran los procesos contenidos en este documento:
Edición 1.8
Página 7 de 155
Edición 1.8
Página 8 de 155
Edición 1.8
Página 9 de 155
4 A1 - ATENCIÓN AL USUARIO
Atención al usuario final ante incidencias, peticiones, consultas y reclamaciones, sobre los servicios
contratados por el cliente, y gestionados por los Centros de Excelencia correspondientes.
OPERATIVA DE ATENCIÓN Y REGISTRO EN CEX Y CEX AVAZANDO POR TRANSFERENCIA DE

LLAMADA EN CALIENTE DE CLIENTE DESDE CGC / 1002
Modalidades:
Esta actividad se realiza en aquellos servicios ya operados por CEx en sus modalidades de CEx
(Estándar) y CEx Avanzado. El idioma de atención en CEx (Estándar) es el castellano y en CEx
Avanzado podrá ser castellano y/o una lengua vernácula.
Servicios:
Aplica para incidencias, peticiones (MNF), y consultas sobre los siguientes servicios:
- Incidencias, peticiones (MNF), y consultas de servicios de DATOS y VOZ integrados en CEx y

gestionados desde GDIA.
Acceso Primario Virtual (APV)

Acceso único IP
Accesos básicos RDSI
Accesos primarios RDSI
Circuito punto a punto internacional*
Circuitos punto a punto
Cloud Connect*
Corporate IP Alojado
DataInternet (incluyendo modalidad Datainternet Lite)
Facilidad SILAN (TIC+ LAN)
FlexUser
flexWAN
flexSITE
FR Internacional
Frame Relay
Ibercom
Ibercom IP en Red
Interconexiones de Fibra Directa
InterLAN
Líneas ocasionales
MACROLAN
MetroLAN
Movistar Corporativo
Nodo de red
Optimización de Aplicaciones en RPVs
STB
VPN FR Internacional*
Edición 1.8
Página 10 de 155
VPN IP
VPN IP Internacional*
* Para estos servicios solo aplica la transferencia de llamada en caliente, desde el CGCi, para la
modalidad CEx Avanzado y sólo en castellano o lenguas vernáculas.
- Incidencias, peticiones (MNF), y consultas de los servicios TI de LAN y Videoconferencia

gestionados desde ARGONAUTA en un ticket REMEDY TI.
Gestión de LAN
iReunion
Proyectos Mantenimiento LAN
Telepresencia
Videoconferencia HD
Actividad:
Esta actividad comprende lo siguiente:
Recibir desde el CGC (1489) o desde el 1002 una transferencia de llamada en caliente de
cliente.
Prestar un servicio de Atención Técnica a cliente para Registro, Seguimiento y Escalado.
Estos CEx recibirán y atenderán en caliente llamadas técnicas directas de los interlocutores
autorizados de sus clientes para los servicios de DATOS y VOZ (GDIA) y los servicios TI de LAN / VCF
(REMEDY TI). Estas llamadas serán transferidas en caliente desde el CGC / 1002 al CEx del cliente
indicado en LOGOS PT y pueden ser por:
Primer contacto de cliente para reportar / registrar una incidencia o una petición de
Modificación No Facturable (no existe ticket registrado).
Necesidad de información (consulta) de cliente sobre un ticket ya existente.
Necesidad de escalado de cliente sobre un ticket ya existente.
Es importante que los CEx tengan correctamente registrados en LOGOS-PT los clientes y servicios que
gestionan, para que la transferencia desde el CGC y el 1002 funcione correctamente y se enruten las
llamadas al CEx correspondiente. Si se detectara algún error, debe corregirse en LOGOS-PT para que
la siguiente transferencia que se realice funcione bien.
Primer contacto de cliente para reportar una incidencia o MNF (no existe ticket registrado):
La transferencia de llamada CGC / 1002 a CEx se realiza siempre (sin excepción).
Implica actividad de Atención en caliente con cliente desde CEx.
Edición 1.8
Página 11 de 155
Implica el Registro desde CEx de un ticket como actividad de Operación.
En caso, de que, por error, al CEx le llegue una llamada que no aplica su atención (tarea NO TÉCNICA
o cliente que no pertenece a ese CEx), éste procederá a:
Devolver la llamada al CGC / 1002 (transferencia al 1489 o al 1002).
Confirmar si en LOGOS PT aparece correctamente el CEx asociado al cliente. Corregirlo si

aplica.
Registrar nuevo ticket en GDIA o REMEDY TI.
Cerrar el ticket indicando las acciones realizadas y su motivo (“Ticket cerrado tras devolución
de llamada a CGC al estar fuera de alcance en el CEx”)
Una vez recibida la llamada de “Primer Contacto” desde el CGC o desde el 1002, el CEx atenderá al
cliente y siempre registrará un nuevo ticket:
Para incidencias o modificaciones no facturables de servicios de DATOS y VOZ, registrará

siempre un ticket en GDIA.
El CEx deben ser muy riguroso en el registro del ticket, marcando siempre adecuadamente su
FASE, su VÍA (siempre “Teléfono”) y su SÍNTOMA.
Averías de servicios de DATOS y VOZ
En GDIA -> Fase = “Explotación” y Vía = “Teléfono”
Modificación no facturable de servicios de DATOS y VOZ
En GDIA -> Fase = “Provisión”, Vía = “Teléfono” y Síntoma = “Modificación No Facturable”
El CEx también deberá marcar si se trata de una “INCOMUNICACIÓN” en la pestaña del ticket
correspondiente. Normalmente esta parte no aplica acción alguna desde CEx ya que se hace
automáticamente al elegir el Síntoma. El CEx debe asegurar que la información refleja lo que
indica el cliente en llamada.
Para servicios de TI de LAN o VCF (solo recibidas desde CGC), el CEx registrará siempre un
ticket en REMEDY TI, tal y como se detalla en la guía operativa de este sistema.
Dicho ticket se asignará al grupo de Remedy correspondiente del CEx:
Para clientes de CEx AVANZADO
“N1_LAN_CEX xx”
Edición 1.8
Página 12 de 155
“N1_VCF_CEX xx”
Para clientes de CEx en modalidad ESTÁNDAR
“N1_LAN_CEX xx” ESTANDAR
“N1_VCF_CEX xx” ESTANDAR
Una vez registrado el ticket y verificado por su parte que la solicitud de cliente debe ser atendida, el
CEx seguirá con el flujo habitual de Operación definido en esta guía, y en las guías operativas de los
propios servicios, para continuar con las demás actividades que procedan en el tratamiento del ciclo
de vida de las incidencias y peticiones.
Además, el CEx siempre deberá anotar, sobre el ticket existente, todas las acciones realizadas por su
parte.
Necesidad de información de cliente sobre un ticket ya existente:
Si CGC / 1002 dispone de toda la información para responder a cliente, éste puede decidir informarle
y no realizar transferencia en caliente al CEx, en caso contrario, la transferencia de llamada del CGC /
1002 a CEx se debe realizar siempre (sin excepción).
Implica actividad de Atención y de Información desde CEx para responder al cliente. En el caso de
que el CEx tampoco disponga de la información tras consultar en las distintas herramientas, deberá
dirigirse al grupo responsable de la gestión del ticket para poder dar respuesta a cliente (en un nuevo
contacto).
o cliente que no pertenece a ese CEx), el CEx procederá a:

aplica.
Documentar el ticket ya existente con las acciones realizadas sobre el ticket existente.
Necesidad de escalado de cliente sobre un ticket ya existente:
La transferencia de llamada CGC / 1002 a CEx se realiza siempre (sin excepción).
Si es ticket GDIA, además de la transferencia al CEx, se realizarán dos acciones adicionales:
CGC / 1002 marcará la casilla de “Escalación” sobre el ticket GIDA para notificar que se ha
reiterado el ticket por cliente.
CGC realizará su operativa habitual de escalado:

Edición 1.8
Página 13 de 155
Clientes Carterizados: envío de mail a Gestor de Servicio.

Clientes no Carterizados: apertura de tarea en AGENDA de “Escalado” a GTA.
Implica actividad de Atención y de Información desde CEx, así como la Gestión del Escalado desde
CEx como actividad de Operación.
o cliente que no pertenece a ese CEx), el CEx procederá a:

aplica.
Documentar el ticket ya existente con las acciones realizadas sobre el ticket existente.
Una vez recibida la transferencia de llamada del cliente para un escalado, el CEx siempre consultará
el estado del ticket registrado (desde GDIA o REMEDY TI).
Posteriormente, gestionará el escalado, asegurándose siempre de que, si es ticket GIDA, se ha

marcado por el CGC /1002 la casilla de “Escalación” sobre el mismo.
Si el escalado no está incluido dentro de la propia actividad del CEx, procederá a aplicar el
procedimiento de escalado definido en el modelo de relación, y contactará con las figuras
responsables de su gestión para su priorización: Gestor de Servicio o GTA.
Flujo operativo:
Actividad en CGC / 1002: Atención + Transferencia de llamada de cliente a CEx:
Recepción de llamada del cliente en CGC / 1002.
Árbol de decisión del Asesor del CGC / Agente del 1002
Asesor Personal (CGC) o Agente (1002) debe determinar que se trata de una llamada técnica
sobre un servicio de DATOS y VOZ (GDIA), o sobre un servicio TI de LAN / VCF (REMEDY TI). Éstas son
las únicas llamadas de cliente que se van a transferir en caliente al CEx.
Determinar si el problema del cliente es técnico sobre uno de estos casos:
Nueva avería / Nueva petición (Modificación No Facturable)
Información / Seguimiento / Consulta / Asesoramiento sobre ticket abierto
Escalado sobre ticket abierto
Determinar el servicio por el que llama el cliente:

Edición 1.8
Página 14 de 155
CGC y 1002: Servicio DATOS y VOZ (GDIA)
Sólo CGC: Servicio TI LAN / VCF (REMEDY TI)
Asesor Personal (CGC) o Agente (1002) transfiere llamada en caliente a CEx
El DDI de cada CEx está automatizado y no debe de ser conocido por el Asesor Personal (CGC)
o por el Agente (1002).
Para transferir:
El Asesor Personal del CGC hace uso de la botonera 40.
El Agente (1002) hace uso de dicha opción en su menú desplegable.
El proceso intenta capturar el número de teléfono de contacto del cliente para iniciar la
transferencia al CEx. Si no lo consigue, saltará un “pide número”.
El Asesor Personal (CGC) o Agente (1002) espera a contactar con un operador del CEx
mientras cliente se mantiene a la espera.
Si el contacto con el CEx se realiza con éxito:
El Asesor Personal (CGC) o Agente (1002) le traslada a un operador del CEx la información
proporcionada por el cliente, mientras éste se mantiene a la espera.
Una vez que el operador del CEx tenga la información, el Asesor Personal (CGC) o Agente
(1002) le transfiere al cliente y cuelga.
Si el contacto con el CEx no se puede realizar (por error en la transferencia, saturación,

incomunicación o contingencia en el CEx), el CGC / 1002 actúa de respaldo:
CGC / 1002 recupera la llamada de cliente y opera de la forma habitual:
Primer contacto de cliente (no existe ticket registrado):
Se registra ticket y se asigna al grupo del CEx en la herramienta.
CGC: ARTE, REMEDY TI
1002: siempre SAC VANTIVE
CGC / 1002 anotará siempre el mail de cliente en los datos de la apertura de la avería para
poder realizar notificaciones de estado por esa vía desde CEx.
Información o Seguimiento (Consulta) sobre ticket ya existente:
Edición 1.8
Página 15 de 155
CGC registra tarea en AGENDA (tipo “Consulta/Asesoramiento”) solicitando información a

GTA.
1002 anota la reiteración en la pestaña “Comentarios” de VANTIVE
Escalado sobre ticket ya existente:
CGC escala a las figuras PVEE:
Cliente carterizado
Remite mail a Gestor de Servicio.
Cliente no carterizado
Registra tarea en AGENDA (tipo “Escalado”) a GTA.
1002 anota la reiteración en la pestaña “Comentarios” de VANTIVE.
Además, si es ticket VANTIVE, CGC / 1002 deben marcar la casilla de “Escalación” para
registrar el escalado.
En caso de que un Asesor Personal (CGC) o Agente (1002) detecte que una llamada se
transfiere hacia un CEx incorrecto (que no gestiona a ese cliente), deberá solicitarle a ese CEx que
revise y actualice la información en LOGOS PT para evitar que el error vuelva a suceder en el futuro.
(*) Se recuerda que no aplica transferencia de llamada a CEx en caso de petición de informe de
avería, o en el caso de que la atención al cliente sea en inglés.
Actividad en CEx: Atención en caliente + Registro + Seguimiento ante llamada de cliente

transferida desde CGC / 1002:
Recepción de llamada en caliente transferida desde CGC sobre un servicio de DATOS y VOZ (GDIA) o
sobre un servicio TI de LAN / VCF (REMEDY TI).
El Asesor Personal (CGC) o Agente (1002) contacta con el operador del CEx y le traslada
brevemente la información proporcionada por cliente. El cliente se mantiene a la espera.
La primera información que recibe el CEx debe ser siempre el teléfono de contacto del
cliente para que, en caso de que la transferencia se corte, el CEx pueda retomar el contacto
realizando una llamada al cliente.
En caso de que se trate de una llamada por un ESCALADO, el CEx siempre debe consultar al
Asesor CGC / Agente 1002 que ha realizado las siguientes tareas:
CGC / 1002: si es ticket SAC VANTIVE, el marcado de la casilla de “Escalación”.
Edición 1.8
Página 16 de 155
CGC: en todos los tickets (VANTIVE o REMEDY TI), el escalado a Gestor de Servicio (mail) / a
GTA (tarea registrada en AGENDA).
Una vez que el operador del CEx tenga toda la información, el Asesor Personal (CGC) o
Agente (1002) le transfiere al cliente y cuelga.
Argumentario / diagnóstico inicial desde CEx en caliente con cliente
Primer contacto de cliente (no existe ticket registrado)
El operador del CEx siempre registrará un ticket para dejar documentadas todas las acciones
realizadas por su parte.
Registro de ticket
REMEDY TI (desde ARGONAUTA)
GDIA
Avería
Fase = “Explotación” y Vía = “Teléfono”
Modificación No Facturable
Fase = “Provisión”, Vía = “Teléfono”, y Síntoma = “Modificación No facturable”
Añadiendo, si aplica, el detalle en la pestaña de “INCOMUNICACIÓN”. El CEx debe asegurar

que la información de esa pestaña refleja lo que indica el cliente en la llamada.
Si la llamada no aplica al CEx (no es cliente de ese CEx, no es servicio GDIA o LAN/VCF
(REMEDY TI), ...), el operador del CEx debe:
Informar a cliente en caliente
Devolver la llamada de cliente al CGC / 1002 (transferencia al 1489 / 1002)

aplica.
Anotar sobre el ticket abierto todas las acciones realizadas
Resolver el ticket abierto detallando el motivo: “Ticket cerrado tras devolución de llamada a
CGC / 1002 al estar fuera de alcance del CEx”
Si la llamada aplica al CEx, el operador del CEx debe:
Edición 1.8
Página 17 de 155
Realizar, en caliente con cliente, las tareas de Operación una vez registrado el ticket en GDIA
o REMEDY TI:
Diagnóstico
Una vez registrada y diagnosticada la avería VANTIVE: realizar la anotación en GDIA de un
nuevo contacto con cliente VÍA “EMAIL” y TIPO “TDE-Cliente” para notificar tanto a cliente como a
CGC su estado.
Informar a cliente en caliente de todo lo realizado. Esto incluye indicar siempre al cliente el
número de ticket registrado (GDIA o REMEDY TI).
Posteriormente, realizar la Transferencia o Resolución
Una vez resuelta la avería GDIA: realizar la anotación en GDIA de un nuevo contacto con
cliente VÍA “EMAIL” y TIPO “TDE-Cliente” para notificar tanto a cliente como a CGC su estado.
Anotar sobre el ticket abierto todas las acciones realizadas.
Información o Seguimiento (Consulta) sobre ticket ya existente

aplica.
Informar a cliente
Si el CEx dispone de la información (directamente o consultando los comentarios del ticket en

GDIA / REMEDY TI), informa a cliente.
Si el CEx NO dispone de la información, consulta con el grupo responsable de la gestión del

ticket. Una vez se tenga la información, informa a cliente (en un nuevo contacto).
Escalado sobre ticket ya existente
Edición 1.8
Página 18 de 155

aplica.
Gestionar el escalado:
Si el escalado está incluido dentro de la propia actividad del CEx, éste realiza su operativa
habitual.
Si el escalado NO está incluido dentro de la propia actividad del CEx, éste procede a aplicar el
procedimiento de escalado, contactando con Gestor de Servicio o con GTA para su priorización.
Informar a cliente
Si es ticket VANTIVE, además, se debe confirmar el marcado de la casilla de “Escalación”.
Sistema de gestión de llamadas:
DDI en CEx:
Cada CEx (Estándar) y CEx Avanzado ha indicado sobre qué DDI va a recibir las transferencias de
llamadas de cliente desde CGC / 1002.
Locución y gestión de colas:

Funcionalidades para la correcta gestión de la transferencia de llamada de CGC / 1002 a CEx
La transferencia de llamada no debe pedirle ningún dato del CEx al asesor del CGC / Agente
del 1002.
Si el operador del CEx está libre, la llamada debe entrar directa.
Si están todos los operadores del CEx ocupados, la llamada se encola y salta una locución que
informa del tiempo de espera estimado para ser atendido.
Edición 1.8
Página 19 de 155
Si hay saturación o incomunicación en el CEx (contingencia activada), salta directamente una

locución indicándolo sin encolar la llamada.
Automatismo de llamada:
Este automatismo permite transferir la llamada de cliente desde CGC / 1002 a CEx sin que el asesor
del CGC o el agente del 1002 deba conocer el teléfono del CEx de destino. A su vez se define la forma
en la que el CGC / 1002 reportará errores en el automatismo, y la forma en la que el CEx debe
encargarse de que se solventen con una actualización en LOGOS PT.
Procedimiento de transferencia (automatismo):

Diariamente, con la información de LOGOS PT, el automatismo genera un fichero que relaciona los
CIF de los clientes de esta iniciativa con el teléfono (DDI) del CEx que tienen asignado para recibir las
transferencias de llamadas de los clientes.
Este fichero se deposita en un servidor de TCRM para que dicha información se incorpore a las
opciones de transferencia del asesor del CGC (botonera 40) / agente del 1002 (menú desplegable).
Cuando un asesor / agente quiere transferir la llamada al CEx, simplemente hace uso de esa botonera
y la llamada se cursa hacia el CEx correcto tras consultar dicho fichero (y sin necesidad de que el
asesor del CGC / agente del 1002 deba conocer el CEx destino).
Para cursar la transferencia, lo que hace el automatismo es intentar capturar el número de teléfono
de contacto del cliente, relacionarlo con el CIF de cliente y, finalmente, obtener el DDI del CEx
consultando el fichero anterior. Si el automatismo no consigue capturar el número de teléfono de
contacto del cliente, saltará un “pide número” al asesor.
Procedimiento para reporte desde CGC / 1002 de error en la transferencia:

En caso de que un asesor del CGC / agente del 1002 detecte que una llamada se transfiere hacia un
CEx incorrecto (que no gestiona a ese cliente), deberá solicitarle a ese CEx que revise y actualice la
información en LOGOS PT para evitar que el error vuelva a suceder en el futuro.
Procedimiento de actualización desde CEx de información (teléfono) en LOGOS-PT:

En caso de que un operador del CEx reciba una transferencia de llamada desde CGC / 1002 sobre un
cliente que no pertenece a ese CEx, deberá revisar y actualizar la información en LOGOS-PT para
evitar que el error vuelva a suceder en el futuro.
El procedimiento para realizar dicha actualización pasa por informar a su Coordinador de Gestión de
TSO para que realice la solicitud formal a los administradores de LOGOS-PT.
Procedimiento de contingencia:
La operativa de actuación ante contingencias en la transferencia de llamadas entre CGC / 1002 y CEx
se centra en los siguientes escenarios:
Edición 1.8
Página 20 de 155
Problemas detectados por el CEx que les impide recibir transferencias de llamadas desde el
CGC / 1002 durante un periodo prolongando de tiempo (+10 minutos).
Caídas de la telefonía en CEx.
Saturación de la telefonía en CEx.
Problemas detectados por el CGC / 1002 que les está impidiendo transferir las llamadas al
CEx durante un periodo prolongando de tiempo (+10 minutos).
Detección desde CGC / 1002 de caídas de la telefonía en CEx.
Detección desde CGC / 1002 de saturación de la telefonía en CEx.
Queda excluida la contingencia por indisponibilidad/caída del sistema GDIA. En ese caso, se recuerda
a los CEx que, una vez informados de su caída, deben seguir la operativa de contingencia publicada
en BTO para estos sistemas. La operativa de transferencia de llamadas desde el CGC / 1002 a CEx, se
mantiene activa independientemente del estado del sistema GDIA.
Comunicación:
La comunicación se realizará por email a los siguientes destinatarios:
Jefes, Coordinadores y RUS de CGC
Jefes y Coordinadores de 1002
Buzón de escalados del CEx + Coordinador de Gestión de TSO
Estos contactos y escalados se encuentran en el modelo de relación en el documento BTO-OYM-GES-

GUI-63801 MODELO DE RELACIÓN EN TAREAS DE ATENCIÓN Y REGISTRO EN CEX Y CEX AVAZANDO.
Operativa:
Activación de Contingencia desde CEx
CEx remite correo electrónico a todos los contactos de CGC, 1002, y CEx:
Solicitando que se paralice temporalmente la transferencia de llamadas
Detallando el problema
Informando del tiempo estimado de resolución
Mientras no se remita el correo de reactivación desde el CEx, las transferencias quedan

temporalmente inactivas.
Edición 1.8
Página 21 de 155
Revisión de posible Contingencia

CGC / 1002 remite correo electrónico a todos los contactos de CGC, 1002, y CEx:
Solicitando que el CEx revise la situación y confirme si se debe paralizar temporalmente la

transferencia de llamadas.
Detallando el problema
CEx revisa lo reportado por CGC / 1002 y remite correo electrónico de respuesta a todos los
contactos del punto anterior:
Detallando si efectivamente existe un problema
Si existe:
Solicitando que se paralice temporalmente la transferencia de llamadas
Informando del tiempo estimado de resolución
Si no existe:
Solicitando al CGC / 1002 que realice nuevas pruebas para verificar que todo funciona
correctamente.
Mientras no se remita el correo de reactivación desde el CEx, las transferencias quedan

temporalmente inactivas.
Resolución de Contingencia desde CEx

CEx remite correo electrónico a todos los contactos de CGC, 1002, y CEx:
Solicitando que se reanude la transferencia de llamadas
Informando de la resolución del problema
Si no se indica lo contrario desde el CGC / 1002, con esta notificación se da por solventada la
contingencia y se retoma la operativa de transferencia de llamadas.
Edición 1.8
Página 22 de 155
5 A3 - MONITORIZACIÓN DE EVENTOS DE LA EXPLOTACIÓN

El objetivo de la actividad es la supervisión proactiva de los servicios filtrando y categorizando
eventos con el fin de realizar las acciones adecuadas en cada caso.
La proactividad y supervisión continua del estado de los equipos presentes en planta gestionada
debe realizase a través del sistema de monitorización WOCU, el cual supervisa el estado de los
equipos a través de un ping IP cíclico a la IP_Gestión configurada en el EDC.
El volcado de EDCs en WOCU es realizado mediante una “Importación” realizada con Origen LOGOS-
PT, que es la CMDB oficial para los servicios de Datos.
(*) No todos los equipos se pueden monitorizar, solo aquellos que tengan una IP de gestión
alcanzable desde el sistema de monitorización.
(*) El detalle de los servicios/elementos monitorizables junto con los packs de monitorización a
asignar está detallado en la tabla resumen incluida en el apartado 5.1 de esta misma guía operativa.
Cumpliendo los dos puntos anteriores, los EDCs pertenecientes a CEx/CGE de los siguientes servicios
disponen de detección + apertura proactiva de incidencias a través del agente ASTRO (más detalle en
BTO-OYM-GES-GUI-65202)
VPNIP.
MACROLAN.
DATAINTERNET (incluyendo la modalidad Datainternet Lite).
RPV INTERNACIONAL.
SILAN (Solo sobre los Switch, no sobre los Access Point).
De cara a que la detección + apertura proactiva de incidencias ofrezca todas sus posibilidades, es
imprescindible cumplir con los siguientes puntos:
Correcta Validación del HOST (mediante Wocu-Check) en el reino WOCU asociado a
cada subservicio lógico (CC).
Correcta habilitación/parametrización a nivel de tipo de persistencia por cada CIF en
Portal Astro (CEx/CGE), (ver Guía Funcional ASTRO para más detalle).
Esta operativa se realiza de forma transparente al CEx.
Habilitación del campo “Plataforma Automática Apertura Tickets” sobre cada EDC
en LOGOS PT, ha de estar HABILITADO o SIN MARCAR; tampoco debe deshabilitarse entre
un rango de fechas.
ACLARACIÓN: Suponiendo el caso de que no esté activada en Wocu la
Importación Ética/LOGOS PT de forma automática, recordamos que aplicará:
Carga automática con CONFIGURATION desde Wocu; campo “PROACTIVIDAD” de
LOGOS PT con el valor “Requiere y SG ok”, campo “Tipo Gestión” de LOGOS PT con valor
Edición 1.8
Página 23 de 155
“ESTANDAR” y el campo “Est.Gestión Especial” LOGOS PT con el valor ACTIVO (estas son
parametrizaciones para carga automática en Wocu, pero no para Astro).
Correcta parametrización del Horario Sede en LOGOS PT: En caso no disponer de
horario de sede en dicho campo, el horario se establece por defecto en base a los
parámetros de criticidad y servicio
Correcta actualización del campo CRITICIDAD sobre cada EDC en LOGOS PT:
Si CRITICIDAD = CENTRAL o CRITICO DE CLIENTE, la apertura + registro proactivo de
tickets funciona en horario 7*24.
Si CRITICIDAD <> CENTRAL o CRITICAL, la apertura + registro proactivo de tickets
funciona únicamente en el horario estándar de los servicios, es decir “L – V de 08:00h a
21:00h” para servicios VPNIP y 7*24 para el resto de los servicios.
Correcta parametrización de los Eventos en Wocu (más detalle en apartados 5.1 y
5.2).
Además, opcionalmente, personalización de horarios por Sede diferenciando días Laborables de días
Festivos (ver Guía Funcional ASTRO para más detalle).
Si el cliente dispone de herramienta de supervisión propia a utilizar por el CEx/CGE; será obligatoria
la solicitud y aprobación de una VTO al servicio CEx que valide la solución especial de monitorización.
En todo el ámbito del servicio CEx/CGE es obligatoria la habilitación de proactividad (detección +

apertura de tickets proactivos), existiendo únicamente la posibilidad de deshabilitación en aquellos
casos que estén correctamente justificados y validados por necesidades de negocio.
WOCU almacena toda la información de eventos/incidentes/problemas que generan la apertura de

un ticket proactivo en su consola para poder ser consultados de forma reactiva durante el
tratamiento de cualquier incidencia.
Dentro de esa identificación de Eventos, dependiendo de su criticidad WOCU los clasificará como
CRITICAL, WARNING, UNRECHABLE. Igualmente, realizará un segundo marcado de criticidad desde el
punto de vista “SOFT” o “HARD”.
Los eventos marcados como SOFT (leves) son aquellos que suponen un corte real sobre el
acceso, pero que muy posiblemente no supongan impacto al cliente (o aunque lo supongan, en
muchas ocasiones el cliente no lo detectará).
Por el contrario, los eventos marcados como HARD (duros) sí que suponen un corte en el
servicio hacia el cliente.
OMEGA abría proactivamente tickets tanto por eventos SOFT como por eventos HARD,
focalizados siempre a eventos de UP/DOWN producidos sobre la interface WAN de cliente.
Edición 1.8
Página 24 de 155
Por el contrario, ASTRO abre únicamente eventos de tipo HARD, pero con un mayor abanico
de detecciones, posibilitando con ello una disminución del volumen de incidencias con origen
“Cliente”. En concreto, este es el desglose de eventos tratados por el agente:
Los eventos W2 y W3 se utilizan para los escenarios de accesos y respaldos móviles, con el
objetivo de detectar posibles pérdidas de conectividad con la Estación Base o detección de
conmutación del protocolo WRR en los casos de respaldos móviles. Para el tratamiento por parte del
agente de este tipo de eventos, es necesario utilizar el pack de Wocu “SNMP Generic”, configurado
con los siguientes parámetros (más información en Guía Funcional ASTRO).
Ante la recepción de cualquier incidencia abierta proactivamente o ante la detección de cualquier

evento CRITICAL en Wocu sobre EDCs que por motivos justificados tengan deshabilitada la apertura
proactiva de incidencias, el CEX/CGE siempre deberá:
Verificación de si la alarma es real, ya que podría tratarse por ejemplo de un fallo en el

sistema de monitorización. Para ello se debe:
Identificar el/los equipo/s afectado/s, consultando por hostname en la CMDB del servicio
LOGOS-PT (servicios de datos y voz para los servidores de llamadas y P/SVA). El objetivo es asegurar
que la parametrización de datos en LOGOS PT es correcta.
Verificar que el EDC dispone de los packs correctos en WOCU; en base a su servicio / modelo
de atención asignado (más información en apartados 5.1 y 5.2).
Determinar si la sede, equipo y/o circuitos afectados están en operación del servicio, es decir
que esté en producción para el Cliente y no se trate de una pre-baja, o una sede cerrada o no
operativa temporalmente. Se deben identificar correctamente las sedes no operativas en WOCU,
según lo indicado en su guía operativa, y en el apartado de la actividad “A22 – Control de inventario”
de esta guía.
Edición 1.8
Página 25 de 155
Si estamos ante una incidencia de incomunicación sobre el circuito principal del servicio,
comprobar si tiene contratado un sistema de respaldo, y de ser así verificar si el sistema de respaldo
se ha activado y está garantizando el servicio. Si el respaldo no se hubiera activado, se presenta una
incomunicación total de servicio.
Comprobar en Wocu (PROBLEMS + EVENTOS – Monitoring) qué alarmas / eventos se han

generado para el EDC afectado, siendo imprescindible verificar tanto los eventos SOFT como los
eventos HARD (más información en la documentación existente en la propia plataforma WOCU).
Verificar en Wocu (PROBLEMS – ASSETS) las gráficas de rendimiento sobre el EDC, de cara a
identificar posibles problemas de cortes/lentitud/saturación de caudal que, aunque no hayan
producido un corte total de comunicaciones al cliente sí que pueden estar afectando a una correcta
prestación del servicio.
Acceder por gestión al EDC de cara a verificar:
Logs.
Descartes / Errores CRC / Flapeos en los diversos interfaces.
Estado de posible saturación en CPU/Memoria. En el supuesto de determinar que no existe

ningún motivo objetivo y testeable que justifique la apertura del ticket proactivo, el CEx/CGE
deberá reportar obligatoriamente la errónea apertura del ticket a las áreas responsables:
Apertura desde Agente ASTRO:
ITSM Argonauta en “Telco Sistemas Producción – Producto (ASTRO) – Tipo (Incidencia).
No detección de eventos en WOCU con incidencia real:
Apertura de INCIDENCIA en https://ctic.tesa/
Composición incorrecta del ticket en GDIA (habiendo comprobado los puntos anteriores).
Por ejemplo, apertura proactiva del ticket por un identificativo erróneo en contra del
procedimiento de apertura para ese servicio.
Email a: automatizacionempresas.mantenimiento@telefonica.com
Referido únicamente a las modalidades CEx y CEx Avanzado (en las cuales aplican los automatismos
RTS de los casos de uso 1 y 10), si el CEx detecta un volumen considerable de incidencias expulsadas
por el autómata hacia el inbox del CEx por la causa #006. Transferencia CEX. Sin datos en Wocu de
los equipos afectados es muy posible que sea originado por problemas de estabilidad en su Reino
Wocu.
Edición 1.8
Página 26 de 155
En ese caso, deberá abrir un ticket en https://ctic.tesa/ de cara a revisión de su reino y posible
reinicio de este (pueden existir problemas de inestabilidad, de saturación de créditos, saturación de
hosts por mala regularización de bajas, etc…).
Existen equipos no monitorizables y servicios donde la monitorización no está integrada en la

actividad del CEx y por tanto no cuentan con proactividad, por lo cual el mantenimiento es reactivo y
será el cliente o usuario el que notifique las incidencias por los canales habilitados para tal efecto.
El cliente tendrá visibilidad de lo que tengamos configurado en WOCU, según la guía operativa de
este sistema, para que pueda ver al igual que el CEx las alarmas de sus equipos monitorizados. Esta
opción solo está disponible para clientes con CEx Avanzado, CEx Premium, y CGE, a través del portal
TEDI.
Para la correcta ejecución de la actividad de monitorización, además se deben seguir las indicaciones
específicas de las guías de los sistemas y servicios implicados.
5.1 PARAMETRIZACIONES WOCU
WOCU es una herramienta de Monitorización que detecta determinados tipos de eventos en

Accesos/Equipos (bien desde el punto de vista incomunicación o bien sin incomunicación, pero sí con
cortes, lentitud, saturaciones de CPU/Memoria, etc…).
Posteriormente, hay que tener en cuenta que siempre y cuando los CEx/CGE tengan correctamente
activada la proactividad ASTRO esas alarmas de incomunicación generarán apertura proactiva de
incidencias en GDIA para los servicios MACROLAN, VPNIP, RPV Internacional, DATAINTERNET
(incluida modalidad Datainternet Lite) y SILAN (sobre los SW, no sobre los iAPs).
Aclaración: En los servicios IBERCOM, FLEXWAN y GLAN no existe vinculación actualmente con
ASTRO, por tanto en ningún caso habrá apertura de incidencias proactivas con vía “Proactiva por
Omega”, aunque las alarmas sean detectadas por Wocu.
Los motivos por los cuáles se abrirán dichas incidencias proactiva serán:
Vía ASTRO:
Apertura de incidencia ante cualquier evento HARD

CRITICAL sobre el EDC/Acceso. Es decir, no únicamente se abrirán para eventos UP/DOWN sobre el
HOST sino también se abrirán incidencias si el evento está marcado como HARD CRITICAL en relación
con “lentitud, cortes, saturación del acceso sin corte para cliente”.
En el supuesto de que un CEx/CGE no tenga habilitada ASTRO, deberá realizar manualmente la

apertura de tickets teniendo en cuenta que:
Edición 1.8
Página 27 de 155
Servicios MACROLAN, VPNIP, DATAINTERNET, IBERCOM, FLEXWAN, GLAN.
CEx abrirá la incidencia proactivamente ante eventos UP/DOWN del EDC/Acceso disponibles
en la parte de HOST en WOCU.
En base a los packs de monitorización utilizados, la herramienta Wocu ofrece información de mayor
detección de eventos; pero ya son Eventos que servirán para un tratamiento reactivo y no proactivo
de la incidencia.
Es decir, un evento CRITICAL que no sea UP/DOWN en la parte de HOST (por ejemplo, alta ocupación
de CPU, MEMORIA, etc…) no supondrá la apertura proactiva de un ticket por parte del CEx; sino que
servirá como información adicional de apoyo en el diagnóstico de una incidencia reportada por el
cliente.
El detalle concreto sobre el funcionamiento/parametrización de la herramienta WOCU se encuentra

documentado en el Manual Operación WOCU.
El detalle concreto sobre el funcionamiento/parametrización de la herramienta ASTRO se encuentra

documentado en Guía Funcional ASTRO.
Deben tenerse en consideración algunos aspectos que detallamos a continuación con el objetivo de
que ningún CEx/CGE reciba exigencias de parametrización que NO corresponden a su modelo de
atención, para evitar inconsistencias que impidan una correcta operación de la Actividad A3 por no
llegar a los mínimos de parametrización que todos los CEx/CGE han de tener en su Reino WOCU.
Las directrices concretas para el servicio FLEXWAN están especificadas en:

BTO-PYM-PYS-GUI-61735 FlexWAN WOCU
Las directrices concretas para el servicio GLAN están especificadas en:

BTO-OYM-GES-GUI-61019 Manual Operación WOCU
15. ANEXO 2 – Actuaciones necesarias para monitorización de equipos GLAN desde WOCU
Las directrices que detallamos a continuación corresponden a los servicios:

MACROLAN, VPNIP, DATAINTERNET (incluidas funcionalidades dependientes), SILAN,
IBERCOM IP, CORPORTE IP ALOJADO, GATEWAY NGN
A) MODALIDAD -- CEx (Estándar) --

En esta modalidad los CEx tienen la obligación de:
Mantener una correcta actualización de planta gestionada en el Reino WOCU asignado, el

cual ha de estar asociado al CC (identificador lógico del subservicio).
Edición 1.8
Página 28 de 155
Es obligatorio, dentro de las responsabilidades de A22 eliminar del Reino WOCU asociado
todos aquellos EDC con pedido LOGOS de BAJA finalizado o con estado claro de PRE-BAJA
identificado y confirmado con cliente/comercial.
Mantener una correcta actualización de planta gestionada en la CMDB oficial del servicio
(LOGOS PT), con la correspondiente activación de proactividad ASTRO en CIFs + EDC.
Es obligatorio, dentro de las responsabilidades de A22, desactivar la proactividad en todos

aquellos EDC con estado claro de PRE-BAJA identificado y confirmado con cliente/comercial
marcándolo en LOGOS PT; así como eliminar de LOGOS PT todos aquellos EDCs con pedidos de BAJA
finalizados que por algún motivo no hayan desaparecido automáticamente de LOGOS PT tras la
finalización del pedido.
Dentro de la tarea (Task) IMPORT_ETICA del reino WOCU asociado, deberá marcarse el check
“REGISTER AS ACTIVE”. Con dicha acción, todos los nuevos EDCs que vuelquen desde un pedido
LOGOS finalizado a planta gestionada en LOGOS PT pasarán automáticamente a la tabla Active Assets
de WOCU sin pasar por Pending; pero en todo momento será preciso realizar WOCU-CHECK para
cumplir con las directrices de A19 especificadas en la guía BTO-PYM-ANS-GUI-46150 INSTALACIÓN Y
CONFIGURACIÓN DE EDCs (apartado Configuración del equipo) descargando con ello el Pack GENERIC-
HOST sobre el EDC gestionado.
Es importante resaltar que para esta modalidad de atención NO deberá marcarse ninguna
otra opción dentro de IMPORT_ETICA.
Igualmente, recordar que en esta modalidad de atención NO Aplican VTOs, por tanto en
ningún caso podrán aceptarse peticiones de clientes que soliciten la activación de “X” packs de
monitorización adicionales para testear otros aspectos avanzados como pueden ser umbrales,
caudales, etc.
Respecto a Hosts pertenecientes a Ibercom IP y Corporate IP Alojado (servidores de llamadas

y servidores de los productos de valor añadido), aplicará el pack GENERIC-HOST.
Respecto a Hosts pertenecientes a Gateway NGN, aplicará el pack GENERIC-HOST.
B) MODALIDAD -- CEx Avanzado --

En esta modalidad los CEx tienen la obligación de:

Edición 1.8
Página 29 de 155

Dentro de la tarea (Task) IMPORT_ETICA del reino WOCU asociado, deberá marcarse el check
“REGISTER AS ACTIVE”. Con dicha acción, todos los nuevos EDCs que vuelquen desde un pedido
LOGOS finalizado a planta gestionada en LOGOS PT pasarán automática a la tabla Active Assets de
WOCU sin pasar por Pending; pero en todo momento será preciso realizar WOCU-CHECK para
cumplir con las directrices de A19 especificadas en la guía BTO-PYM-ANS-GUI-46150 INSTALACIÓN Y
CONFIGURACIÓN DE EDCs (apartado Configuración del equipo) descargando con ello el Pack GENERIC-
HOST sobre el EDC gestionado.
IMPORTANTE: En esta modalidad, deberán seguirse estrictamente las indicaciones de las

guías BTO-PYM-ANS-GUI-46150 INSTALACIÓN Y CONFIGURACIÓN DE EDCs (apartado Activación del Conector
JANO (WOCU – Portal Autogestión)) y BTO-OYM-GES-GUI-61019 Manual Operación WOCU (apartado
INTEGRACION CON PORTAL AUTOGESTION – TEDI - (JANO)) para activar el conector que permita al cliente
visualizar las gráficas de sus EDCs de planta gestionada a través de Portal Autogestión – MiGedi.
Es importante resaltar que para esta modalidad de atención NO deberá marcarse ninguna
otra opción dentro de IMPORT_ETICA, aunque sí es recomendable que el GdST (que sí existe en esta
modalidad) asigne desde CONFIGURATION el pack NETWORKDEVICE-PING.
Igualmente, recordar que en esta modalidad de atención NO Aplican VTOs, por tanto en
ningún caso podrán aceptarse peticiones de clientes que soliciten la activación de “X” packs de
monitorización adicionales para testear otros aspectos avanzados como pueden ser umbrales,
caudales, etc….

C) MODALIDADES -- CEx PREMIUM / CEx PREMIUM PLUS / CGE --

La obligación de los CEx/CGE de estas modalidades SI que es visualizar las alarmas/eventos
directamente en la plataforma WOCU y actuar en consecuencia ante ellas; partiendo siempre de esta
base:
Edición 1.8
Página 30 de 155


Dentro de la tarea (Task) IMPORT_ETICA del reino WOCU asociado, quedará a expensas del
CEx/CGE marcar o no “REGISTER AS ACTIVE”; aunque la recomendación para estas modalidades es
NO marcarlo, dado a que habrá que añadir algunos otros packs de monitorización que detallamos a
continuación:
Si se marca el check, todos los nuevos EDCs que vuelquen desde un pedido LOGOS finalizado
a planta gestionada en LOGOS PT pasarán automáticamente a la tabla Active Assets de WOCU sin
pasar por Pending.
En el supuesto de no marcarse, los nuevos EDCs pasarán a la tabla Pending.
Será obligación de los CEx/CGE de las modalidades indicadas en este punto:
Añadir desde CONFIGURATION el pack NETWORKDEVICE-PING.
Marcar en la tarea (Task) IMPORT_ETICA el check “DISCOVER PACK”, el cual aplicará sobre
los EDCs los paquetes de monitorización “NETWORKDEVICE-MEM” y “NETWORKDEVICE-CPU”.
Posteriormente, tanto con “Register As active” marcado como desmarcado, deberá siempre
realizarse WOCU-CHECK para cumplir con las directrices de A19 especificadas en la guía BTO-PYM-
ANS-GUI-46150 INSTALACIÓN Y CONFIGURACIÓN DE EDCs (apartado Configuración del equipo).
IMPORTANTE: En esta modalidad, deberán seguirse estrictamente las indicaciones de las

guías BTO-PYM-ANS-GUI-46150 INSTALACIÓN Y CONFIGURACIÓN DE EDCs (apartado Activación del Conector
JANO (WOCU – Portal Autogestión)) y BTO-OYM-GES-GUI-61019 Manual Operación WOCU (apartado
INTEGRACION CON PORTAL AUTOGESTION – TEDI - (JANO)) para activar el conector que permita al cliente
visualizar las gráficas de sus EDCs de planta gestionada a través de Portal Autogestión – MiGedi.
Edición 1.8
Página 31 de 155
Aclarar que en estas modalidades de gestión sí que puede aplicar perfectamente

tramitación de VTOs para parametrizaciones personalizadas de umbrales, caudales, etc…. pero
siempre teniendo presente que NO deben parametrizarse esos otros packs adicionales (como por
ejemplo pueden ser NETWORKDEVICE-TRAFFIC o similares) si no existe VTO CEx que respalde la
actividad no estándar que origina la aplicación de estos packs.

Además, dependiendo de la tecnología del Hosts habrá que añadir:
CISCO: call-manager-cisco-snmp + call-manager-cisco.
ALCATEL OXE: linux-snmp + snmp-oid-1m
OSV UNIFY: linux-snmp + snmp-oid-1m
MITEL-MX ONE: mxone-basic + mxone-advanced
SBC ORACLE: sbc-acme-packet-ibercom
5.1.1 SISTEMA DE CRÉDITOS COMPARTIDOS
Esta información está disponible en el submenú “Documentation” de la propia herramienta Wocu
https://wocu.tesa/aggregator/docs/ (Recomendamos acceso a dicho módulo para información

de mayor detalle).
Dentro de ese link, en el apartado “MÓDULOS ADICIONALES – Sistema de control y penalización por
exceso de activos a monitorizar”.
Edición 1.8
Página 32 de 155
La información de créditos disponibles por Reino es visible a través del Menú CONFIGURATION.
Igualmente, recomendamos el acceso al Menú “ASSETS – PACKS” para visualizar a nivel global qué
PACKS están mapeados en cada Hosts:
En el supuesto de ser necesario solicitar aumento de créditos asignados sobre un Reino Wocu, debe
realizarse desde https://ctic.tesa/ - PETICION "Síntoma = Aumento de Créditos" por parte del
Responsable de Administración de Usuarios del proveedor.
Otras peticiones relacionadas con Wocu que pueden realizarse son:
a) Renombrar un Reino ya existente:

Edición 1.8
Página 33 de 155
El Responsable de Administración de Usuarios del proveedor ha de abrir Ticket en https://ctic.tesa/

+ PETICION + Síntoma = Renombrado Reino Wocu.
Excepción: Únicamente en aquellos centros donde NO existe operación por parte de los
proveedores, la petición será realizada por el GdST asignado en LOGOS PT.
b) Migración de Reino de un Cliente:

+ PETICION + Síntoma = Migración de reino de un cliente.
c) Baja reino Wocu:

+ PETICION + Síntoma = Baja reino Wocu (Visor-Satélites).
d) Regularización hosts&servicios Wocu:
El GdST asignado al CEx/CGE en LOGOS PT ha de abrir Ticket en https://ctic.tesa/ + PETICION +

Síntoma = Regularización hosts & Servicios Wocu
5.2 CUADRO RESUMEN DE PARAMETRIZACIONES WOCU
Adjuntamos cuadro resumen por modalidades/servicio:
CEx CEx Avanzado CGE / CEx Premium / Premium +
MACROLAN Task: ETICA_IMPORT Task: ETICA_IMPORT Task: ETICA_IMPORT
VPNIP “Register As Active” = NO

“Register As Active” = “Register As Active” =
DATAINTERNET
“Discover geocoordinates” =
“Discover geocoordinates” = “Discover geocoordinates” =
(incluido DINET
LITE) “Discover packs” =
Generic-Host = Generic-Host =
SILAN
Edición 1.8
Página 34 de 155
Generic-Host =
BTO-OYM-
GES-GUI-61019 Networkdevice-ping = Networkdevice-ping =
QoS =
Task: ETICA_IMPORT
Task: ETICA_IMPORT “Register As Active” = NO
Task: ETICA_IMPORT
“Register As Active” = “Discover geocoordinates” =
RESPALDOS
MÓVILES VPNIP “Register As Active” =
y ACCESOS “Discover geocoordinates” = “Discover packs” =
4G/5G
DATAINTERNE “Discover geocoordinates” =
Generic-Host = Generic-Host =
T (afecta a los
eventos W2 y
Generic-Host =
W3 de ASTRO) Networkdevice-ping =
Networkdevice-ping =
SNMP Generic = SNMP Generic =
QoS =
Task: ETICA_IMPORT Task: ETICA_IMPORT Task: ETICA_IMPORT
Task: FlexWan_IMPORT Task: FlexWan_IMPORT Task: FlexWan_IMPORT
“Register As Active” = NO
“Register As Active” = “Register As Active” =
“Discover geocoordinates” = “Discover geocoordinates” =
FLEXWAN
IMPORT_FLEXWAN
IMPORT_FLEXWAN IMPORT_FLEXWAN
BTO-PYM-PYS-
GUI-61735 Flexwan-pack-host =
Flexwan-pack-host = Flexwan-pack-host =
Flexwan-pack =
Flexwan-pack = Flexwan-pack =
Flexwan-Syslog =
Flexwan-Syslog = Flexwan-Syslog =
Networkdevice-ping-1m =
Networkdevice-ping-1m = Networkdevice-ping-1m =
GLAN 1 1 1
get-config-and-modules get-config-and-modules get-config-and-modules
BTO-OYM-
Edición 1.8
Página 35 de 155
1 1 1
networkdevice-available-ports networkdevice-available-ports networkdevice-available-ports
2 2 2
networkdevice-cpu networkdevice-cpu networkdevice-cpu
2 2 2
networkdevice-mem networkdevice-mem networkdevice-mem
GES-GUI-61019
3 3 3
cisco-wifi-controller cisco-wifi-controller cisco-wifi-controller
4 4 4
aruba-alcatel-wifi-controller aruba-alcatel-wifi-controller aruba-alcatel-wifi-controller
5 5 5
aruba-alcatel-wifi-iAP aruba-alcatel-wifi-iAP aruba-alcatel-wifi-iAP
Task: ETICA_IMPORT
“Register As Active” = NO
Task: ETICA_IMPORT
Task: ETICA_IMPORT Generic-Host =
“Register As Active” =
“Register As Active” = (*) Dependiendo tecnología:
IBERCOM IP y
CORPORATE IP “Discover geocoordinates” = CISCO: call-manager-cisco-snmp +
ALOJADO “Discover geocoordinates” = call-manager-cisco.
Generic-Host =
ALCATEL: linux-snmp +
Generic-Host =
snmp-oid-1m
UNIFY: linux-snmp + snmp-oid-1m
MITEL: mxone-basic + mxone-

advanced
SBC: sbc-acme-packet-ibercom
Task: ETICA_IMPORT Task: ETICA_IMPORT Task: ETICA_IMPORT
“Register As Active” = “Register As Active” = “Register As Active” =

GATEWAY NGN
“Discover geocoordinates” = “Discover geocoordinates” = “Discover geocoordinates” =
Generic-Host = Generic-Host = Generic-Host =
NO SI SI
¿Conector JANO?
BTO-PYM-
Edición 1.8
Página 36 de 155
ANS-GUI-46150
¿Posibilidad VTO
NO NO SI
CEx?
PACKS OPCIONALES, no requieren VTO.

1
Aplica para el servicio GLAN. Es necesario en iAP Aruba, Controladora Aruba, Controladora Cisco, iAP Cisco y en todos los modelos
de SWITCHES.
2
Aplica para el servicio GLAN. Es necesario todos los modelos de SWITCHES. En el caso concreto de SW Enterasys, están realizándose
pruebas para personalizar los packs “Enterasys-cpu” y “Enterasys-mem”, pero aún no están en producción y por tanto todavía no
aplican.
3
Aplica para el servicio GLAN. Es necesario en iAP Cisco y Controladora Cisco.
4
Aplica para el servicio GLAN. Es necesario Controladora Aruba.
5
Aplica para el servicio GLAN. Es necesario iAPs Aruba.
Edición 1.8
Página 37 de 155
5.3 GESTION REACTIVA
GESTIÓN DE LA DISCONFORMIDAD DEL CLIENTE ANTE INCIDENCIAS CERRADAS EN LAS QUE

CONSIDERA QUE EL PROBLEMA NO ESTA RESUELTO
Objetivo:
Dar una respuesta al Cliente de forma Reactiva en tiempo y forma a la comunicación de
disconformidades en la resolución de las averías, esta disconformidad la manifiesta el Cliente en las
encuestas telefónicas de calidad en una pregunta muy específica para ello.
Estas disconformidades son del tipo “Avería no Resuelta”.
Dicho proceso impacta de forma directa en la satisfacción del Cliente sobre nuestro servicio, ya que
es el motivo más importante que provoca insatisfacción.
Uno de los objetivos de este proceso es evitar las averías reiteradas, dando una oportunidad al
Centro de Gestión de solucionar el problema con el Cliente, sin provocar la reiteración.
Mejorar la nota de satisfacción de los Clientes sobre el servicio de mantenimiento y atención de

averías de los Servicios de Empresa.
Proceso:
En primer lugar, es importante saber la metodología que se sigue en el desarrollo de las encuestas al
Cliente relacionadas con el mantenimiento de los Servicios de Empresa:
Servicios de datos: MacroLAN, VPN IP, DataInternet y FlexWan.
Servicios de voz: Ibercom Master, Ibercom IP, Corporate IP Alojado, e Ibercom IP en Red.
Solo se tendrán en cuenta para este proceso las averías que hayan sido gestionadas por los Centros
de Gestión de todas las modalidades, es decir, toda incidencia que tenga ticket GDIA.
A diario se crea un universo a Encuestar partiendo del total de averías cerradas el día anterior
y al cual se le aplican unas exclusiones ya definidas con los responsables de los servicios. Con ello se
genera el llamado Publico Objetivo “PO”. Una de las exclusiones que se realizan es verificar si existe
una nueva avería abierta sobre el circuito asociado, sea cual sea el servicio, en el caso de que exista
ya una se descarta el registro de la encuesta. Esta comprobación se hace sobre las 08:30 de la
mañana que es cuando se genera el PO.
El día de su creación se inician los intentos de llamadas al contacto definido, si no se puede

establecer contacto, se mantiene un día más. Eso quiere decir que la encuesta siempre se realizará al
día laborable siguiente al cierre o como mucho al siguiente.
Edición 1.8
Página 38 de 155
El proceso abarca todo el desarrollo de atención y resolución de averías de los servicios de empresa,
viene a suplir la carencia actual en el tratamiento de la insatisfacción de los Clientes debido a averías
no resueltas.
Actividad:
Puntos principales del proceso:
- Esta soportado básicamente por las encuestas de calidad realizadas al día siguiente del
cierre de la avería.
- Se basa en las respuestas a esta pregunta concreta:
RES: En esta pregunta el Cliente manifiesta que el problema por el cual abrió la avería persiste ya sea
en su totalidad o en parte. Al responder negativamente desencadena el proceso de la creación de la tarea en
agenda, en este punto el agente le informa de que pasa el problema nuevamente al Centro de Gestión, y el
Cliente se quedará pendiente de la llamada del Centro de Gestión. La encuesta finaliza en este punto y no se le
pregunta al Cliente su valoración sobre el servicio.
- Proceso automático. En el momento de realizar la encuesta y producirse esta opción, el

proceso automático desencadena la apertura de una tarea en GDIA al buzón del Centro
de Gestión responsable de la incidencia. Dicha tarea tiene lo siguientes campos:
A87607917 EMPRESA AVERIA_NO_CONFO IBERCOM IP Vantive- 7456162 - 7456162 30-abr-21 "Esta Tarea viene de la encuesta realizada al Cliente,
MUNICIPAL DE RME_FRANQUEO IBERCOM IP - CIF: es una averia franqueada Causa Cliente y el Cliente
SERVICIOS A87607917 - ha manifestado que no esta conforme con la
FUNERARIOS DE EMPRESA imputacion del Franqueo, hay que analizar la averia
MADRID, S.A. MUNICIPAL DE y llamar al Cliente y aclarar con el el motivo del
SERVICIOS cierre y si necesita alguna ayuda mas por parte de
FUNERARIOS DE Telefonica.
MADRID
// Vantive - 7456162 // Persona Contacto -
JULIOBENITO // Telefono - 915108157 // Fecha y Hora
de la Encuesta - 30/04/2021 11:25 // Comentario del
Cliente - No sabe porque ocurrió. "
A28063675 LABORATORIOS AVERIA_NO_RESUEL MacroLAN Vantive- 7455169 - 7455169 29-abr-21 "El objeto de esta tarea es gestionar la reclamacion
HIPRA S.A. TA MacroLAN - CIF: manifestada por el Cliente en la encuesta de
A28063675 - satisfaccion realizada una vez que se ha cerrado la
LABORATORIOS averia y que dice que aun sigue mal. Se ruega se le
HIPRA S.A. llame al telefono de contacto del cliente y se le
pregunte que problema tiene, hay que hacer lo
necesario para poder solucionar el problema del
Cliente, si es necesario se abrira una nueva averia.
Una vez que se cierre esta tarea, se le volvera a
llamar al Cliente para ver si ha quedado todo
correcto.
// Vantive - 7455169 // Persona Contacto - XAVIER

VILA // Telefono - 616768447 // Fecha y Hora de la
Encuesta - 29/04/2021 14:55 // Comentario del
Cliente - no lo supieron solucionar "
Edición 1.8
Página 39 de 155
- Estos datos son de referencia para que el operador localice la avería en GDIA y se
documente sobre lo ocurrido.
- La tarea se abrirá de forma automática en el buzón del Centro de Gestión responsable,
de forma paralela se enviará un correo al Centro de Gestión, avisando de su apertura y
adjuntando los datos y el link directo a dicha tarea para facilitar su tratamiento, como se
puede ver en este ejemplo:
- La tarea se presentará en GDIA con el siguiente formato:
Edición 1.8
Página 40 de 155
- Una vez llegado a este punto es donde el Centro de Gestión entra en acción.
Puntos importantes para tener en cuenta antes de actuar el Centro de Gestión:

Esta información viene directamente de la voz del Cliente y como es obvio es visión Cliente,
hay que intentar ser empático y enfocar el problema desde el punto de vista del Cliente.
La encuesta ha sido realizada sobre una avería franqueada y cerrada, eso quiere decir que
todo lo que se ha realizado debe estar correcto, pero el Cliente no lo ve así.
Hay que tomar una actitud de escucha, compresión y enfocarlo todo a solucionar el
problema del Cliente y no a justificar nuestra actuación.
Hay que ser crítico sobre nuestra actuación y pedir disculpas al Cliente si no lo hemos hecho
todo lo bien que él esperaba.
La mayoría de los problemas que se plantearán, son problemas que técnicamente ya están
solucionados, pero el Cliente no ha comprendido bien lo que ha sucedido. Muchas veces se darán
situaciones complejas de entender por el Cliente, pero hay que hacer un esfuerzo para que el Cliente
lo entienda y se sienta entendido.
El objetivo no es solo solucionar técnicamente el problema, sino que el Cliente se sienta
entendido, atendido y comprendido.
Evitemos justificaciones y echarles la culpa a otros departamentos de Telefónica, Telefónica
somos todos, hay que buscar soluciones y no culpables.
Preparativos previos antes de llamar al Cliente:

Tomar como referencia la incidencia GDIA, leerla y situarse en la avería. Llamar al Cliente
dando la impresión de que nos hemos preocupado de ver su problema y no solo para preguntarle
qué le pasa.
No perder de vista el posible histórico de la avería, esto muchas veces puede ser el origen del
problema ya que puede ser un tema reiterado.
Revisar si existe ya otra nueva avería abierta, aunque en el momento de crear el PO se
verifica este punto, puede darse el caso de que se haya abierto hace unas horas y no se haya podido
detectar, esto simplificaría el procedimiento, ya que posiblemente la solución al problema ya este
encaminada. De todas formas, hay que leer e informarse sobre el estado de esta nueva avería para
poder informar al Cliente.
La llamada al Cliente:
- IMPORTANTE llamar al teléfono que se indica en la Tarea, ese es el teléfono de la
persona que ha hecho la encuesta y es quien ha dado la valoración.
- Lo normal es que la persona sea la misma que ha gestionado la avería por parte del
Cliente ya que el contacto para llamar y hacer la encuesta viene del contacto de la avería.
- Mantener una actitud receptiva ante el Cliente, ya el simple hecho de llamarlos de forma
proactiva sitúa al Cliente en una buena actitud para iniciar la conversación.
- Escuchar, entender y no justificar, ser empáticos y buscar soluciones.
- Dedicarle tiempo, dejar que el Cliente se exprese, seguramente esté disgustado,
dejémosle que se calme y ofrezcámosle escucha y comprensión.
- No entremos en discusiones sin sentido.
- Si mantenemos todas estas pautas, seguramente el problema se solucionará, la mayoría
son malentendidos o franqueos con explicaciones poco entendibles por parte del Cliente.
Edición 1.8
Página 41 de 155
- Se debe llamar al cliente cuanto antes, a poder ser el mismo día en que se recibe la tarea
de agenda en GDIA, teniendo en cuenta que el tiempo trascurrido entre la realización de
la encuesta y la apertura de la tarea suele ser de una hora aproximadamente. Numero de
intentos a realizar:
o Si la tarea entra antes de las 12h: Se deben realizar 3 intentos ese mismo día y 3
intentos más al día hábil siguiente.
o Si la tarea entra después de las 12h: Se debe intentar contactar con el Cliente al
menos una vez ese mismo día y si no se consigue se deben realizar 3 intentos diarios
más durante los 2 días hábiles siguientes.
- Todos los intentos de contacto con el Cliente se deben dejar registrados en los
comentarios de la tarea dejando constancia del teléfono al que se ha llamado. Una vez
agotados todos los intentos de contacto con el Cliente definidos sin conseguir contactar
con él, se debe finalizar la tarea registrando en los comentarios “Cliente ilocalizable”.
- Si una vez contactado el Cliente no nos puede atender en ese momento, podemos
aplazar la realización de la gestión reactiva como máximo 2 días hábiles.
- El operador se deberá presentar como Centro de Gestión.
Registro de la actuación del CEx/CGE:

Una vez revisada la avería reclamada por parte del operador, se procederá a llamar al Cliente
e informar en la tarea abierta en GDIA.
Para facilitar la gestión se han tabulado varias opciones a las distintas cuestiones a tratar con
el Cliente.
Dentro de la tarea de GDIA se pulsará en la pestaña “Acciones” una vez ahí, pulsar “Añadir
nuevas acciones”, la tarea a seleccionar en tipo de gestión seria “COMENTARIO PARA ENCUESTA”.
Edición 1.8
Página 42 de 155
PROBLEMA: Identificar dentro del desplegable el problema que manifieste el Cliente, como
ejemplo, en el caso de que el Cliente diga que la avería no está resuelta, la opción más lógica seria
“AVERIA MAL CERRADA”.
¿SE HABÍA INFORMADO CORRECTAMENTE AL CLIENTE DEL CIERRE?: Esta cuestión está muy
relacionada con la gestión de información realizada en los contactos de primer diagnóstico,
evolución, observación y cierre de la incidencia, realizados al cliente también por SMS e Email
durante el tratamiento de la incidencia, indicar la opción que más encaje.
Edición 1.8
Página 43 de 155
SOLUCION APORTADA AL CLIENTE: Indicar la solución que se le aporta al Cliente. Importante

en el caso de abrir una nueva avería o que ya exista, apuntar dicha avería en el cuadro indicado. ( ID
TICKET ABIERTO NUEVO).
¿NECESARIO ABRIR UNA NUEVA AVERÍA DESDE EL CEx EN ESTA GESTIÓN?: Es importante
seleccionar de forma correcta, ya que, al acabar el proceso, al Cliente se le volverá a llamar para que
valore nuestra actuación, en el caso de que no se haya abierto avería se encuestará por la misma,
pero en el caso de que se haya abierto alguna, se encuestará por la nueva.
Edición 1.8
Página 44 de 155
MOTIVO APERTURA NUEVO TICKET: Seleccionar la opción que se corresponde con el motivo
de la apertura del nuevo ticket.
- ¿HA QUEDADO SATISFECHO CON LA GESTION REALIZADA?: Indicar la percepción del

Cliente, es muy normal que en los casos de nuevas aperturas de avería se use la opción
de “ESPERANDO A VER QUE PASA”.
Edición 1.8
Página 45 de 155
- ID TICKET ABIERTO NUEVO: Indicar el número del ticket GDIA de la nueva incidencia y sin
espacios, es un campo para indexar.
- COMENTARIOS: Describir lo más detallado posible la gestión realizada. Este espacio es

importante para revisar todo lo que se ha hecho para solucionar el problema al Cliente.
- Una vez rellena todas las opciones, pulsar “Añadir nuevas acciones” y se quedará
registrada la acción.
- FINALIZACION DE LA TAREA: Una vez informada, dentro de la pestaña “Datos generales

tarea” pulsar “Finalizar” y la tarea cambiará su estado.
Edición 1.8
Página 46 de 155
Una vez se ha informado en la tarea todo lo anterior, ésta se cierra, incluso en los
casos en los que se determine que se abra una nueva avería, la tarea se informa y se
finaliza. Cuando se cierre la nueva avería abierta, se volverá a encuestar al Cliente
por la nueva avería, teniendo en cuenta en la encuesta que esta nueva avería, su
origen ha sido una avería anterior con una tarea de gestión reactiva por parte del
Centro de Gestión.
Fin de la actuación del Centro de Gestión:

Una vez finalizada la tarea de GDIA, la gestión del Centro de Gestión termina. Ahora una vez
que se cierre la tarea y en los casos en que exista una avería nueva, se esperará a que se
cierre y se volverá a encuestar al Cliente. En esta nueva encuesta, se le preguntara si el
problema está resuelto y además por su valoración de 0-10 sobre su satisfacción con el
servicio y además sobre su valoración sobre la gestión reactiva realizada por el Centro de
Gestión.
MUY IMPORTANTE: Estas tareas de petición de Gestión Reactiva le llegan al Centro de

Gestión sin que el Cliente haya valorado su satisfacción sobre la actuación de Telefónica en la
avería, esta valoración se le pedirá una vez realizada la Gestión Reactiva.
Edición 1.8
Página 47 de 155
Esto quiere decir que preguntarle a un Cliente si la avería esta solucionada, que nos conteste
que NO, y que luego le preguntemos por la valoración, lo más probable, y así ocurre, es que
su valoración sea un suspenso, además de no reaccionar ante el Cliente por decírnoslo
claramente en la encuesta, a no ser qué el propio Cliente vuelva a abrir la avería y en muchos
casos generará averías reiteradas.
Con este nuevo proceso, encaminamos nuevamente al Cliente al Centro de Gestión, dando la
oportunidad de buscar una solución al problema por parte del Centro de Gestión y una vez
tratado, se le encuestará de nuevo al Cliente y en esta segunda encuesta es cuando se le
preguntará sobre su valoración del servicio, esto provocará que la valoración del Cliente en
estos casos tendera a ser positiva.
Edición 1.8
Página 48 de 155
6 GESTIÓN DEL CICLO DE VIDA DE LAS INCIDENCIAS, PETICIONES, CONSULTAS

Y RECLAMACIONES
El centro de excelencia es responsable extremo a extremo de la gestión de las incidencias, peticiones,
consultas y reclamaciones que se detecten en el servicio de forma proactiva o lleguen al servicio de
forma reactiva debiendo quedar todas ellas registradas en el sistema de ticketing, GDIA, junto con
toda la información de su ciclo de vida de forma que mediante su consulta sea posible para el resto
de áreas reconstruir lo ocurrido incluyendo esto en los campos de información obligatoria, usuarios
con los que se ha contactado, pruebas diagnósticas realizadas y todo aquello que permita no repetir
acciones ya realizadas que ralenticen la resolución de la incidencia.
Un problema o una necesidad de nuestros clientes debe ser un asunto nuestro, y dado que
conocemos de primera mano la urgencia o necesidad que tienen, es responsabilidad del CEx/CGE ser
la voz del cliente y transmitir esa necesidad o urgencia a las demás áreas que intervienen en el
tratamiento de las incidencias y peticiones.
6.1 A4 - REGISTRO
Todas las incidencias, peticiones, consultas y reclamaciones deberán quedar registradas en el sistema
de ticketing corporativo, excluyéndose solamente aquellas incidencias que quede demostrado que
no lo son durante las pruebas realizadas en A3, fase de Monitorización, es decir, no se registrarán las
derivadas de errores de monitorización. Para los servicios de datos y de voz el sistema de ticketing
principal es GDIA.
En el caso de las incidencias, una vez registradas se debe informar al cliente de su apertura reflejando
la realización de este contacto en el ticket de GDIA tal como se indica en el ANEXO 2: PLAN DE
COMUNICACION A CLIENTE.
El registro de las incidencias se hace de manera automática o manual.
La primera opción siempre debe ser la automática, y para ello se rige a través del agente de
detección de alarma + registro “ASTRO”, aplica para todas las modalidades CEx/CGE.
Obligatoriamente han de cumplirse todos los requerimientos descritos en el apartado 5 de esta

misma guía operativa de cara a asegurar un funcionamiento óptimo de la proactividad.
El registro manual se debe emplear en todos los casos donde el autómata de ASTRO no haya
registrado automáticamente la incidencia. En este caso se debe comprobar el motivo por el cual no
se realizó, y si es debido a que no estaba activado el campo “Plataforma Automática Apertura
Tickets” en LOGOS-PT, se debe corregir para que no vuelva a ocurrir.
Cuando se crea un ticket de incidencia ya sea de forma automática o manual, los datos del
interlocutor de cliente de referencia en la incidencia son cargados de los sistemas (HERA, LOGOS-PT),
o introducidos manualmente por el CGC/CEx cuando hacen el registro de la incidencia.
Edición 1.8
Página 49 de 155
- Independientemente de donde procedan, estos datos deben confirmarse con el cliente y

actualizarse en el ticket en caso de que no sean correctos o el interlocutor de cliente para
la incidencia sea otro. Es importante identificar correctamente al interlocutor de cliente
de referencia de la incidencia para mantenerle informado adecuadamente a lo largo del
ciclo de vida de esta, y documentarlo correctamente en el ticket.
En los CGE que no son 7x24, en horario fuera de horas será el CEx Estándar correspondiente el que
lleve a cabo la proactividad.
- Para ello el CGE debe tener debidamente marcada la criticidad del equipo en LOGOS-PT
(Central, Crítica). Además, ha de estar activada y marcada la funcionalidad de gestión
“Proactividad” para que se envíen las alarmas al sistema de supervisión.
En LOGOS-PT también debe estar documentado el horario de cada sede y el teléfono de contacto.
- En los casos en los que haya un contacto distinto fuera del horario de la sede, se debe
registrar como teléfono secundario, para que el CEX (Estándar) fuera de horas pueda
consultarlo en LOGOS-PT en caso de registro manual del ticket, o si la apertura la hace
ASTRO automáticamente, se incluya este dato en el mismo.
En el caso de que un CGE que no sea 7x24 tenga prevista la realización de trabajos en alguna sede
central o crítica fuera de su horario, deberá marcar en el apartado correspondiente a Datos Omega
en la pestaña “Equipo” en LOGOS-PT el intervalo en el cual no se debería realizar la proactividad por
parte del CEx Estándar fuera de horas, para evitar la apertura de tickets innecesarios, además de
informarle por correo o teléfono de esta circunstancia.
Cuando el CGE no 7x24 se incorpore de nuevo, deberá autoasignarse las incidencias que el CEx
Estándar fuera de horas haya dejado en el buzón fuera de horas para retomar su tratamiento. Los
Inbox fuera de horas no permiten la asignación en bloque de incidencias, debiendo hacerse una a
una.
ACLARACIÓN “Fuera de Horas”: En aquellos CGEs “NO 7*24”, el tratamiento de las incidencias
“Fuera de Horas” es el siguiente:
- Durante el horario del CGE propietario de la gestión del EDC/acceso; el ticket se encuentra
ubicado en el Área GDIA de dicho CGE.
- En el momento que el CGE finaliza su turno, debe asignar los tickets desde GDIA hacia el Área de
desborde del CEx encargado de dicha operación “Inc GS CExNN_F. Horas”.
- Durante el horario de desborde, el CEX encargado de dicha operativa identificará los tickets con
esta casuística desde el filtro “FUERA DE HORAS”.
Edición 1.8
Página 50 de 155
- El CEx de desborde, si consulta cualquiera de dichos tickets en el Interface GDIA identificará como
Área del ticket “Inc GS CExNN_F. Horas”.
- Cuando el CGE responsable de la gestión del EDC/acceso vuelve a su horario, deberá recuperar y
autoasignar sus tickets. Para ello, desde su propia Área GDIA, deberá acceder al filtro “OTRAS
ÁREAS” o a “TICKETS-CEx” y desde ahí, podrá consultar los tickets sobre los cuáles desarrollar
dicha acción.
 Registro automático de la incidencia en GDIA desde ASTRO:

Las alarmas de los EDCs, que se recogen en WOCU a través de las colectoras correspondientes,
pueden ser tratadas de forma automática por medio de los agentes ASTRO.
Dichos agentes realizan diversas comprobaciones para determinar que la alarma que está
tratando corresponde realmente a una anomalía en el funcionamiento del EDC o circuito, y
registran la incidencia en GDIA.
A través de LOGOS-PT, se permite interactuar con algunos parámetros de ASTRO para activar y
customizar este automatismo, siguiendo lo indicado en la guía operativa de WOCU y en la Guía
Funcional Astro.
El automatismo registrará las incidencias con los siguientes parámetros:
El Síntoma es “Proactiva”
Edición 1.8
Página 51 de 155
El campo sumary de la alarma se copia literalmente en el campo Descripción.

La vía de recepción es “ProActivo por Omega”.
Apertura desde ASTRO:Usuario de registro USWSAC.
Se deben comprobar estos datos, y especialmente que el síntoma es el indicado, de lo contrario

se debe actualizar una vez que se empiece a tratar la incidencia.
Si el automatismo recibiera una alarma incorrecta por fallo en el sistema de gestión y la

registrará, el operador deberá modificar el síntoma a “Fallo en Servicio de Supervisión” y
cerrarla indicando en la solución de GDIA la Causa “Fallo en Servicio de Supervisión”.
La apertura de tickets se ha de realizar preferiblemente de manera automática por ASTRO. En

caso contrario se debe registrar la incidencia manualmente siguiendo las indicaciones de la Guía
Operativa interface SAC/GDIA.
 Registro manual de la incidencia en SAC desde SAC-GDIA:

Para registrar una incidencia en GDIA se debe gestionar desde la Aplicación GDIA, en el apartado
de Herramientas, seleccionando el vínculo a “Interfaz SAC-GDIA”, y una vez allí abrirla mediante
el icono “Crear Nuevo Ticket”.
Para caracterizar una incidencia tendremos que evaluar la vía de entrada, la fase en que está, el
servicio afectado, la facilidad (si aplica), el identificativo del elemento afectado y el síntoma.
Las vías de entrada establecidas son:
Proactiva:
ASTRO, cuya vía de recepción para el CEx sería GDIA, al hacerse el registro automático.
WOCU, sistema de monitorización, requiere registro manual.
Actuaciones preventivas de mantenimiento como BTP, RI, pruebas de backup, etc., cuya vía
de recepción sería “Proactivo por rutina”, requiere registro manual.
Revisiones proactivas solicitadas por el Centro de servicio Ibercom o el gestor de Centrex,

cuya vía de recepción sería “CACE”.
Reactiva:
Correo, mail a buzón genérico por parte del Cliente.
Teléfono, llamada telefónica.
Portal MiGeDi, cuya vía de recepción para el CEx sería GDIA, al hacerse el registro
automático.
Edición 1.8
Página 52 de 155
Otros sistemas de ticketing de cliente, no son estándar y necesitan una VTO CEx tramitada, y
solo aplicarían para las modalidades Premium, Premium Plus y CGE*
(*) En los casos en los que el cliente demande el registro de la actividad en herramienta propia, esto
no exime del uso obligatorio en tiempo y forma de la herramienta corporativa de Telefónica. El
tratamiento de la actividad debe corresponderse con los hitos del ciclo de vida de las incidencias, no
siendo válido el registro a posteriori o una vez finalizada la incidencia.
En las siguientes tablas vemos las vías de entrada para las incidencias, peticiones (MNF), consultas y
reclamaciones, tipo de actividad, así como las vías de recepción para los CEx/CGE según la modalidad
de gestión contratada:
 CEx (Estándar) y CEx Avanzado:
CEx y CEx Avanzado (Atención +

Operación)
Vía Vía
Origen Vía Entrada Actividad Acción Acción
Recepción Recepción
Cliente CGC registra ticket en CEx recibe ticket en
Incidencias Correo GDIA
ARTE GDIA
(Reactivo) Peticiones CGC registra ticket en CEx recibe ticket en
Correo GDIA
(MNF) ARTE GDIA
Información: CGC
Correo informa a cliente sobre
(Correo a CGC) ticket SAC existente en Información: CEx puede
ARTE y abre tarea de recibir llamada de GTA.
Consultas y
Correo Agenda al GTA. Teléfono Escalado: CEx puede
reclamaciones
Escalado: CGC marca la recibir llamada de GS o
reiteración en el ticket GTA.
existente en ARTE y
escala a GS/GTA
Teléfono
(Llamada a CGC CGC o 1002 trasfiere CEx atiende llamada en
o 1002) llamada en caliente al Teléfono / caliente y registra ticket
Incidencias Teléfono
CEx, o registra ticket en GDIA en GDIA, o recibe ticket
ARTE en GDIA
CGC o 1002 trasfiere CEx atiende llamada en

Peticiones llamada en caliente al Teléfono / caliente y registra ticket
Teléfono
(MNF) CEx, o registra ticket en GDIA en GDIA, o recibe ticket
ARTE en GDIA
Consultas y Teléfono Información: CGC o Teléfono / Información: CEx

reclamaciones 1002 informa a cliente GDIA atiende llamada e
sobre ticket existente, o informa a cliente sobre
trasfiere llamada en ticket SAC existente, o
caliente al CEx. puede ver comentario
Escalado: CGC o 1002 del 1002 en ticket
transfiere llamada en existente en GDIA.
caliente al CEx, reitera Escalado: CEx atiende
ticket, y escala vía llamada en caliente y
correo al GS o Agenda escala, o ve comentario
al GTA del 1002 en ticket
existente en GDIA, o
recibe llamada del GS o
GTA
Edición 1.8
Página 53 de 155
GS, DoP, GTA, GdX

CEx atiende llamada y
Teléfono / atiende al cliente y
Incidencias Teléfono registra ticket en GDIA
Correo llama al CEx para que
(via: CACE)
Teléfono / registre ticket
Correo GS, DoP, GTA, GdX
(Llamada o CEx atiende llamada y
Peticiones Teléfono / atiende al cliente y
correo al Teléfono registra ticket en GDIA
(MNF) Correo llama al CEx para que
Gestor de (via: CACE)
registre ticket
Servicio (GS),
Director de GS/DoP/GTA/GdX
oficina de atiende al cliente y
proyecto (DoP), revisa documentación
Gestor técnico Consultas y en el ticket de GDIA CEx atiende llamada,
avanzado (GTA) escalados Teléfono / para informarle. Solo en informa al
Teléfono
y Gestor de (sobre tickets Correo los casos en los que no GS/DoP/GTA/GdX y
Centrex (GdX)) abiertos) esté debidamente documenta el ticket
documentado en GDIA
llamará al CEx para
consultar
Service Desk atiende al

cliente y registra ticket
en Portal DWP, hace un
Teléfono / Teléfono / prediagnóstico y si el CEx recibe ticket en
Correo Incidencias GDIA
Correo problema está en el GDIA
(Llamada / Macrolan/ VPNIP o
Correo a Datainternet transfiere
Service Desk ticket a CEx
(SD))
Service Desk llama a CEx informa al SD y
Consultas y Teléfono /
CEx para informarse e Teléfono actualiza información
reclamaciones Correo
informa al cliente en el ticket de GDIA
Service Desk recibe
ticket, hace un
prediagnóstico y si el
CEx recibe ticket en
Incidencias Portal DWP problema está en el GDIA
GDIA
Portal DWP Macrolan/ VPNIP o
(Autogestión) Datainternet transfiere
ticket a CEx
Service Desk llama a CEx informa al SD y
Consultas y
Portal DWP CEx para informarse e Teléfono actualiza información
reclamaciones
informa al cliente en el ticket de GDIA
Incidencias GDIA
Portal MiGeDi GDIA
(Autogestión) Peticiones CEx recibe ticket en
GDIA
(MNF) GDIA
ASTRO Incidencias GDIA
GDIA
WOCU WOCU CEx recibe alarma en
(Solo si falla Incidencias (solo si falla WOCU, y registra ticket
ASTRO) ASTRO) en GDIA
CEx visualiza pedidos
Telefónica
GDIA / LOGOS en PROV/GDIA y
LOGOS Provisión
LOGOS gestiona los pedidos en
(Proactivo)
LOGOS.
Trabajo CEx recibe correo e
Trabajos
Programado Correo informa al cliente del
programados
(BTP) trabajo programado.
Actividad fuera CEx registra ticket RASO
N/A Correo
de sistemas en GDIA
Edición 1.8
Página 54 de 155
Previo a un trabajo en
Revisión de cliente CdS registra
Gestión CEx recibe ticket en
tareas y ticket GDIA al CEx para GDIA
interna GDIA
configuración que revise los equipos
de primer nivel
BJ Previo a un trabajo en
cliente GdX envía
CEx recibe correo y
Revisión de correo al CEx o registra
Gestión Correo / registra ticket en GDIA
tareas y ticket GDIA para que el
interna GDIA o CEx recibe ticket en
configuración CEx revise los EDCs de
GDIA
los servicios de
conectividad
Provisión
Centros de servicio o
servicios Gestión CEx recibe ticket en
instalador registra GDIA
Ibercom Ip y interna GDIA
ticket en GDIA
CoIp alojado
Peticiones Gestión CdS Provisión Ibercom CEx recibe ticket en

GDIA
Telefónica (MNF) interna registra ticket en GDIA GDIA
BJ
(Reactivo) Instalador llama al CEx y
CEx atiende llamada,
le facilita pedido LOGOS
registra ticket en GDIA
o administrativo o
Provisión Gestión y, si lo necesita,
nemónico del equipo Teléfono
servicio Centrex interna consulta en ATEx el
sobre el que el CEx
proyecto técnico de
debe realizar las
Centrex
comprobaciones
 CEx Premium y CGE:
CEx Premium y CGE (Atención + Operación)
Origen Vía Entrada Actividad Vía Recepción Acción Vía Recepción Acción
Cliente CEx recibe correo de cliente
Incidencias Correo
(Reactivo) y registra ticket en GDIA
Peticiones CEx recibe correo de cliente
Correo
(MNF) y registra ticket en GDIA
Correo Información: CEx recibe
(Correo a CEx) correo de cliente, e informa
a cliente sobre ticket
Consultas y
Correo existente en GDIA. Escalado:
reclamaciones
CEx recibe correo de cliente,
y escala el ticket SAC
existente en GDIA
Teléfono CEx recibe llamada de
(Llamada a CEx) Incidencias Teléfono cliente, y registra ticket en
GDIA
CEx recibe llamada de
Peticiones
Teléfono cliente, y registra ticket en
(MNF)
GDIA
Consultas y Teléfono Información: CEx recibe
reclamaciones llamada de cliente, e
informa a cliente sobre
ticket existente en GDIA.
Escalado: CEx recibe
llamada de cliente, y escala
el ticke existente en GDIA
Edición 1.8
Página 55 de 155
GS, DoP, GTA,

GdX atiende al CEx atiende llamada y
Teléfono /
Incidencias cliente y llama al Teléfono registra ticket en GDIA (via:
Correo
CEx para que CACE)
registre ticket
Teléfono / Correo
(Llamada o correo al
GS, DoP, GTA,
Gestor de Servicio
GdX atiende al CEx atiende llamada y
(GS), Director de Peticiones Teléfono /
cliente y llama al Teléfono registra ticket en GDIA (via:
oficina de proyecto (MNF) Correo
CEx para que CACE)
(DoP), Gestor
registre ticket
técnico avanzado
(GTA) y Gestor de GS/DoP/GTA/GdX
Centrex (GdX)) atiende al cliente
y revisa
documentación
Consultas y en el ticket de
escalados GDIA para CEx atiende llamada,
Teléfono / informarle. Solo informa al
Teléfono
Correo en los casos en GS/DoP/GTA/GdX y
los que no esté documenta el ticket
debidamente
documentado en
(sobre tickets GDIA llamará al
abiertos) CEx para
consultar
Service Desk
atiende al cliente
y registra ticket
en Portal DWP,
hace un
Teléfono / prediagnóstico y
Incidencias GDIA CEx recibe ticket en GDIA
Correo si el problema
está en el
Teléfono / Correo Macrolan/ VPNIP
(Llamada / Correo a o Datainternet
Service Desk (SD)) transfiere ticket a
CEx
Service Desk
CEx informa al SD y actualiza
Consultas y Teléfono / llama a CEx para
Teléfono información en el ticket de
reclamaciones Correo informarse e
GDIA
informa al cliente
Edición 1.8
Página 56 de 155
Service Desk
recibe ticket,
hace un
prediagnóstico y
si el problema
Incidencias Portal DWP GDIA CEx recibe ticket en GDIA
está en el
Macrolan/ VPNIP
o Datainternet
Portal DWP transfiere ticket a
(Autogestión) CEx
Service Desk
CEx informa al SD y actualiza
Consultas y llama a CEx para
Portal DWP Teléfono información en el ticket de
reclamaciones informarse e
GDIA
informa al cliente
Incidencias GDIA CEx recibe ticket en GDIA

Portal MiGeDi
(Autogestión) Peticiones CEx recibe ticket en GDIA
GDIA
(MNF)
CEx recibe ticket en sist.
Otros Sist.
Incidencias Ticketing de cliente, y
Ticketing
CEx recibe ticket en sist.
Peticiones Otros Sist.
Ticketing de cliente, y
(MNF) Ticketing
Información: CEx recibe
Otros Sist. Ticketing solicitud de información en
(necesario VTO) ticket del sist. Ticketing de
cliente, e informa a cliente
Consultas y Otros Sist. sobre ticket existente en
reclamaciones Ticketing GDIA.
Escalado: CEx recibe
escalado en ticket del sist.
Ticketing de cliente, y escala
el ticket existente en GDIA
ASTRO Incidencias GDIA CEx recibe ticket en GDIA
WOCU WOCU CEx recibe alarma en

Incidencias WOCU, y registra ticket en
(Solo si falla GDIA
(Solo si falla ASTRO)
ASTRO)
Telefónica CEx visualiza pedidos LOGOS
(Proactivo) LOGOS Provisión GDIA / LOGOS en PROV/GDIA y gestiona
los pedidos en LOGOS.
CEx recibe correo e informa
Trabajo Programado Trabajos
Correo al cliente del trabajo
(BTP) programados
programado.
Actividad fuera CEx registra ticket RASO en
N/A Correo
de sistemas GDIA
Edición 1.8
Página 57 de 155
Previo a un
trabajo en cliente
Revisión de CdS registra
tareas y Gestión interna ticket GDIA al CEx GDIA CEx recibe ticket en GDIA
configuración para que revise
los equipos de
primer nivel
BJ
Previo a un
trabajo en cliente
GdX envía correo
Revisión de al CEx o registra CEx recibe correo y registra
tareas y Gestión interna ticket GDIA para Correo / GDIA ticket en GDIA o CEx recibe
configuración que el CEx revise ticket en GDIA
los EDCs de los
servicios de
conectividad
Centros de
Provisión
servicio o
servicios
Gestión interna instalador GDIA CEx recibe ticket en GDIA
Ibercom Ip y
registra ticket
CoIp alojado
GDIA
CdS Provisión
Peticiones
Gestión interna Ibercom registra GDIA CEx recibe ticket en GDIA
(MNF)
ticket GDIA
Telefónica
BJ
(Reactivo) Instalador llama
al CEx y le facilita
pedido LOGOS o CEx atiende llamada,
administrativo o registra ticket en GDIA y, si
Provisión
Gestión interna nemónico del Teléfono lo necesita, consulta en
servicio Centrex
equipo sobre el ATEx el proyecto técnico de
que el CEx debe Centrex
realizar las
comprobaciones
Existen áreas internas que pueden solicitar actividad a los CEx/CGE. Todos los tickets que se registren
para dejar constancia de esta actividad deberán hacerse indicando “Vía Origen” = CACE en GDIA y
Fuente reportada=Evento de BMC Impact Manager en ARGONAUTA. A continuación se detallan las
áreas y los motivos que pueden solicitar actividad a los CEx:
- Figuras de atención: Gestor de Servicio (GS), Director de oficina de Proyecto (DoP), Gestor
técnico avanzado (GTA) y Gestor de Centrex (GdX): Podrán llamar por teléfono al CEx para:
o Solicitar el registro de incidencias o modificaciones no facturables que le reporta el

cliente y en ese momento no pueden registrar. En estos casos, el GS, DoP, GTA o GdX
llamará al CEx/CGE para su registro y tratamiento.
Estos tickets deberán abrirse como Vía: “CACE” y el CEx deberá informar en el campo
Descripción del ticket “Ticket abierto por solicitud de <nombre y apellidos de la
persona que lo solicita> <cargo de la persona que lo solicita (GS, DoP, GTA, GdX)>”.
Edición 1.8
Página 58 de 155
Solo se podrá pedir al CEx que registre los servicios que gestiona como N1.
Consultar o escalar incidencias o modificaciones no facturables abiertas siempre que

la herramienta de ticketing no contenga la información solicitada.
Además, en el caso del gestor de Centrex aplica también el siguiente supuesto:
o Revisión de tareas y configuración: Previo a un trabajo en cliente el gestor de Centrex

puede solicitar vía mail al CEx que revise el servicio de conectividad para asegurar la
correcta configuración y funcionamiento del mismo.
La solicitud deberá generarse con una antelación mínima de 72 horas laborables de
antelación.
- Centros de servicio Provisión Ibercom: El CdS podrá generar ticket al CEx en los siguientes
supuestos:
o Revisión de tareas y configuración : Previo a un trabajo en cliente el CdS puede

solicitar al CEx que revise el servicio de conectividad para asegurar la correcta
configuración y funcionamiento del mismo.
El CdS deberá generar estos tickets con 72 horas laborables de antelación.
En el caso de que el CEx detecte un problema que no se pueda resolver antes de la

visita contactará con el CdS para informarle. En el caso en el que sea necesario abrir
incidencia para solucionar el problema se informará de la misma en el ticket abierto
para la revisión de configuración. La incidencia de revisión de configuración quedará
abierta hasta que se confirme que los equipos que se deben revisar están ok.
En el caso en el que el trabajo solicitado por el CdS esté amparado por un pedido
LOGOS sin finalizar se informará al CdS del estado del mismo y se cerrará la
incidencia.
o Modificación no facturable: El CdS solicita al CEx la necesidad de aplicar una nueva

configuración en el EDC. Dicha configuración deberá ser estándar del servicio o estar
respaldada por VTO del servicio gestionado que valide la configuración solicitada y
VTO del servicio CEX que valide que dicha configuración se hace desde el CEx/CGE.
En este caso deberán indicar en el ticket el número de ambas VTOs.
El CdS deberá generar estos tickets con 72 horas laborables de antelación.
o Soporte primer uso: Si el CdS está realizando una provisión y surge un problema y
necesita que el CEx revise/actúe sobre el servicio de conectividad. El CdS abrirá un
ticket y el CEx deberá ponerse en contacto con el técnico a la mayor brevedad para
realizar conjuntamente las pruebas necesarias.
o Únicamente en los modelos de atención CEx Premium, CEx Premium + y CGE, el CdS
podrá requerir una reunión con el GdSt ante el arranque de un proyecto de ToIp para
Edición 1.8
Página 59 de 155
confirmar la correcta disponibilidad de configuración en los EDCs WAN gestionados

(denominado por CdS Kick-Off de arranque).
ACLARACIÓN: Para todos los supuestos (del CdS) enumerados anteriormente, siempre será
obligatorio que exista un ticket en GDIA generado por el Centro de servicio (con Vía: CACE),
en caso contrario el CEx instará al CdS a registrar el ticket y solamente a partir de ese
momento es cuando el CEx procederá a atender al CdS.
- Instaladores del servicio Centrex: El instalador del servicio Centrex podrá contactar con el
CEx/CGE si durante la instalación del servicio Centrex aparecen problemas y es necesario
revisar la conectividad de los equipos de datos y/o hacer pruebas conjuntas con el CEx/CGE.
El instalador deberá facilitar el pedido LOGOS o el administrativo/nemónico del equipo sobre
el que el CEx debe realizar las comprobaciones.
A continuación, se describe cómo establecer la fase de servicio en que está una incidencia:
Fase de servicio “Explotación”: todas las incidencias tendrán como fase de servicio
“Explotación”, excepto aquellas recogidas en los siguientes casos en los que la fase de servicio será
“Provisión”.
Fase de servicio “Provisión”:
Edición 1.8
Página 60 de 155
- Todas aquellas que tengan un pedido LOGOS de alta, baja o modificación sin finalizar, que
tengan una incidencia y no se pueda tratar por provisión.
- Pedidos finalizados en LOGOS que una vez finalizado el tiempo RASER el cliente no ha
realizado las pruebas de aceptación del servicio. Aquí se incluyen las pruebas que Ibercom necesite
realizar con CEx en las altas de GW NGN/RDSI. Para más detalles, se deben consultar las guías de
provisión e instalación que apliquen.
- Provisión de RPV Internacional, para registrar las actuaciones que se realizan en la provisión
de la modalidad Distribuidora, es decir para clientes nacionales con sedes en el extranjero.
- Para pruebas de Cliente en fase de provisión, en el caso de que el cliente contacte para
realizar las pruebas pendientes, se comprobará si ha pasado menos de un mes desde la firma del
pedido SGC/LOGOS, y se abrirá un ticket con los siguientes parámetros:
Fase: Provisión
Síntoma: El que corresponda
Descripción: Soporte Primer uso
Si pasado el mes en el que se marquen con estos criterios, entrara una incidencia de
cliente para la que se detectará que correspondería con “pruebas RASER”, el CEX
podrá cambiar la Fase a “Provisión” indicando el motivo.
Los CEX realizarán las pruebas pendientes y, una vez que se finalicen, cerrarán el
ticket. Si durante las pruebas el cliente no está conforme con lo que se le ha
tramitado o pide algo que suponga una solución o proyecto especial, se le
comunicará que deberá tratarlo vía comercial en un nuevo pedido y se cerrará la
incidencia.
- Incidencias provocadas durante la ejecución de una orden RI (Reasignación Interna) en la

cual se ha avisado a cliente y se ha establecido una ventana de corte para la realización de la orden.
- Aquellas incidencias que se abren para dejar constancia de un trabajo programado (BTPs y
CRQs), sobre el cual el cliente ha sido previamente informado, y que se han ocasionado durante su
ejecución en la ventana de corte acordada con cliente. El detalle de actuación en los BTPs y CRQs se
encuentra en el documento correspondiente en la BTO.
- Revisión de tareas y configuración: Tickets reportados por el CdS Ibercom Provisión o el

gestor de Centrex para que el CEx revise la configuración del servicio de conectividad previo a la
visita del técnico al cliente (se incluyen en este punto las solicitudes de reuniones de arranque de
proyectos de ToIp).
- Soporte de primer uso: Tickets registrados durante la provisión de una sede de Ibercom o
Centrex porque se ha requerido la intervención del CEx/CGE durante la instalación del servicio de voz
(para revisión de configuración o conectividad del servicio de datos o realización de pruebas
conjuntas con el instalador del servicio de voz).
Edición 1.8
Página 61 de 155
- Modificaciones no facturables, se deberá registrar como Fase “Provisión” y Síntoma

“Modificación No Facturable” aquellas actuaciones derivadas de modificaciones no facturables
solicitadas por el Cliente, por el CdS Ibercom o por el gestor de Centrex, sin pedido LOGOS asociado,
ligadas al EDC y centralitas (Por ejemplo: Reconfiguración de QoS, IP LAN, Rutas Estáticas, ACL, DHCP,
configuración de teclas, grupos de salto, desvíos...).
Estos tickets se cerrarán como:
Responsable: Cliente
Localización: Dependiendo del servicio, donde se haya realizado la
configuración.
Causa: Configuración desde el Centro de Gestión.
Comentarios: Breve resumen de la modificación realizada indicando los datos
de la persona que solicita dichos cambios.
No se podrán abrir como modificación aquellos cambios derivados de un problema

en el servicio (por ejemplo, lentitud ocasionada por QoS mal configuradas) que se
resuelven modificando la configuración del EDC.
Es importante documentar debidamente este tipo de tickets, indicando claramente

quién solicita la Modificación, las causas y el trabajo realizado.
Además, se deben seguir las indicaciones del documento BTO-PYM-PYS-GUI-9120

GUI_SOPORTE A LAS MODIFICACIONES NO FACTURABLES.
(*) Las Modificaciones No Facturables (MNF) son en cualquier caso una actividad de
mantenimiento asociada a la actividad “A13-Cambios de Configuración”, que deberá
ser tratada según los parámetros de cualquier actividad de mantenimiento, su
registro como Fase “Provisión” es solo a nivel de sistemas.
El servicio, facilidad si aplica, y elemento afectado, se obtienen de las CMDBs LOGOS-PT o CIBERUN, y
el sistema de ticketing GDIA los autocompleta. En caso de que durante la gestión de la incidencia se
identificara que estos campos son incorrectos se corregirán, o se registrará un nuevo ticket.
En el registro del ticket también se debe recoger el identificativo, o identificador universal del acceso
afectado, y el parámetro secundario, o Identificativo adicional del acceso afectado, como se muestra
en la siguiente tabla:
ASOCIACIÓN SERVICIOS - TIPO DE IDENTIFICATIVO
DOMICILIO Y CIF EN VALIDACIÓN EN

SERVICIO Y FACILIDAD PARÁMETRO PRINCIPAL PARÁMETRO SECUNDARIO
REGISTRO APERTURA
Tipo Valor identificativo Param.Sec. a
Facilidad Tipo Parám.Sec. Registro manual CIF- Validación RCC
SERVICIO Servicio GDIA Identificativo a cargar en cargar en
GDIA Argonauta Domicilio Servicio+Facilidad
Argonauta GDIA/Argonauta GDIA/Argonauta
DATAINTERNET o
Datainternet - NO.
DATAINTERNET - NAD Administrativo - - DATAINTERNET BANDA
Acceso fijo Se extrae de Logos-PT
ANCHA
Edición 1.8
Página 62 de 155
SI -> Si se identifica DATAINTERNET o

Datainternet - Teléfono de la
DATAINTERNET - NAD Administrativo Telefono que es un Acceso DATAINTERNET BANDA
Acceso móvil SIM
Móvil ANCHA
DATAINTERNET o
DATAINTERNET Redes Limpias NO.
Datainternet (1) NAD Administrativo - - DATAINTERNET BANDA
(no aplica LITE) Se extrae de Logos-PT
ANCHA
FlexSite sobre NO.
DATAINTERNET FlexSite NAD Administrativo EDC Nemónico FlexSite
Datainternet Se extrae de Logos-PT
Número de
Ibercom Máster IBERCOM - Identificativo Teléfono Fijo - - SI IBERCOM
afectado (DDI)
Ibercom Ip
Ibercom Ip Hosted Número de
O365 NGN Lite IBERCOM IP - Identificativo Teléfono Fijo - - SI IBERCOM IP
SBC On premise afectado (DDI)
SBC Virtual
Número de
Centrex Ip
CENTREXIP - Identificativo Teléfono afectado - - SI Ibercom Ip en red
FlexUser
(DDI)
NO.
Macrolan MacroLAN - NAD Administrativo - - MACROLAN
Se extrae de Logos-PT
SILAN sobre NO.
MacroLAN SILAN NAD Administrativo EDC Nemónico SILAN
Macrolan Se extrae de Logos-PT
Cloud
SILAN WIFI sobre Usuarios - NO.
MacroLAN NAD Administrativo EDC Nemónico SILAN
Macrolan SILAN WIFI Se extrae de Logos-PT
GCU
FlexSite sobre NO.
MacroLAN FLEXSITE NAD Administrativo EDC Nemónico FlexSite
Macrolan Se extrae de Logos-PT
GW NGN IP sobre Gateway para Teléfono fijo NO. Gateway para NGN PBX-
MacroLAN NAD Administrativo Telefono
Macrolan NGN PBX-IP afectado Se extrae de Logos-PT IP
GW NGN RDSI sobre Gateway para Teléfono fijo NO. Gateway para NGN PBX-
MacroLAN NAD Administrativo Telefono
Macrolan NGN PBX-RDSI afectado Se extrae de Logos-PT RDSI
ADSL Teléfono
NO.
VPN IP -Acceso fijo VPN IP - (o NAD en (o Administrativo en - - VPN IP
excepciones) * excepciones) *
SI -> Si se identifica
VPN IP -Acceso Teléfono de la
VPN IP - NAD Administrativo Telefono que es un Acceso VPN IP
móvil SIM
Móvil
ADSL Teléfono
NO.
SILAN sobre VPN IP VPN IP SILAN (o NAD en (o Administrativo en EDC Nemónico SILAN
Cloud
ADSL Teléfono
VPN IP (o NAD en (o Administrativo en EDC Nemónico SILAN
VPN IP SILAN WIFI Se extrae de Logos-PT
GCU
ADSL Teléfono
FlexSite sobre VPN NO.
VPN IP FLEXSITE (o NAD en (o Administrativo en EDC Nemónico FlexSite
IP Se extrae de Logos-PT
FlexSite sobre línea Teléfono línea NO.
VPN IP FLEXSITE ADSL EDC Nemónico FlexSite
residencial residencial Se extrae de Logos-PT
ADSL Teléfono
GW NGN IP sobre Gateway para Teléfono fijo NO. Gateway para NGN PBX-
VPN IP (o NAD en (o Administrativo en Telefono
VPN IP NGN PBX-IP afectado Se extrae de Logos-PT IP
ADSL Teléfono
GW NGN RDSI sobre Gateway para Teléfono fijo NO. Gateway para NGN PBX-
VPN IP (o NAD en (o Administrativo en Telefono
VPN IP NGN PBX-RDSI afectado Se extrae de Logos-PT RDSI
NO.
FlexWan FlexWAN - Id Sede FlexWAN Id Sede FlexWAN EDC Nemónico FLEXWAN
SILAN sobre NO.
FlexWAN SILAN Id Sede FlexWAN Id Sede FlexWAN EDC Nemónico SILAN
FlexWan Se extrae de Logos-PT
Cloud
FlexWAN Id Sede FlexWAN Id Sede FlexWAN EDC Nemónico SILAN
FlexWan SILAN WIFI Se extrae de Logos-PT
GCU
FlexSite sobre NO.
FlexWAN FLEXSITE Id Sede FlexWAN Id Sede FlexWAN EDC Nemónico FlexSite
FlexWan Se extrae de Logos-PT
RPV
RPV Internacional - NAD Administrativo - - SI RPV INTERNACIONAL
INTERNACIONAL
RPV CLOUD
Cloud Connect NAD Administrativo - - SI RPV INTERNACIONAL
INTERNACIONAL CONNECT
Circuitos punto a Circuitos punto a NO.
- NAD Administrativo - - -
punto Internacional punto Se extrae de Logos-PT
Edición 1.8
Página 63 de 155
Internacional
Circuitos punto a Circuitos punto a NO.
- NAD Administrativo - - -
punto punto Se extrae de Logos-PT
DWDM
Interconexiones INTERCONEXIÓN CPD o
Interconexiones de - NAD El valor introducido - - SI
de Fibra Directa INTERCONEXIÓN LAN
Fibra Directa
VSAT VSAT - NAD El valor introducido - - SI VSAT
RED
RED INTELIGENTE - Identificativo El valor introducido - - SI -
INTELIGENTE
Interlan
Datalan Interlan - NAD El valor introducido - - SI INTERLAN
Datavoz
NO.
Metrolan Metrolan - NAD Administrativo - - METROLAN
STB
RDSI/RTC de cliente
NO.
LINEA ADSL /FTTH Residencial - Identificativo Teléfono - - -
TELEFONICA.NET /
LINEA ADSL
Frame Relay
NO.
Frame Relay ADSL Frame Relay - NRI NRI - - FRAME RELAY
Frame Relay Canal B
IBERPAC BASICO
IBERPAC PLUS
NRI (o
IBERPAC X75 Red UNO - Identificativo - - SI IBERPAC o UNO
Administrativo)
UNO
UNO IP VOZ
NRI (o
ATM ATM - - - SI ATM
Identificativo Administrativo)
Nodo de red Nodo de red - NRI NRI - - SI NODO DE RED
SOLUCIONES SOLUCIONES
DATOS Identificativo El valor introducido - - SI SOLUCIONES ESPECIALES
ESPECIALES ESPECIALES
VOZ Identificativo El valor introducido - - SI SOLUCIONES ESPECIALES
OTROS Identificativo El valor introducido - - SI SOLUCIONES ESPECIALES
SOLUCIONES SOLUCIONES MULTIOPERA SOLUCIONES ESPECIALES
Identificativo El valor introducido - - SI
ESPECIALES ESPECIALES DOR (2) + MULTIOPERADOR
En azul casos sin Validación de Planta.
En azul casos sin Validación RCC
* Excepciones con Identificativo NAD para VPNIP los tipos de circuito: Móviles, ATM, FR, X.25
(1) Provisionalmente, todas las incidencias de Datainternet "Caudal Agregado" deberán abrirse desde el interface SAC VANTIVE.
(2) Sólo se puede utilizar esta facilidad cuando el cliente haya contratado el servicio Multioperador gestionado desde CGE.
Los síntomas disponibles son múltiples y debemos tratar de elegir el que mejor describe la situación
que provoca la incidencia. Lo primero que debemos saber es que una incidencia que se registra de
forma automática reflejará en el campo “Síntoma” el valor “Proactiva” por defecto y
obligatoriamente debe modificarse para reflejar el síntoma real durante la vida de la incidencia. Los
síntomas que se deben utilizar son los definidos a continuación:
SERVICIO/FACILIDAD SÍNTOMAS
Modificación no Facturable
Todos los servicios ACTUACIONES PREVENTIVAS DE MANTENIMIENTO
Fallo en acceso a monitorización
PROBLEMAS TRAFICO E/S
PROBLEMA CALIDADES DE SERVICIO
Teléfono averiado
Ibercom
Línea alto impacto cliente.
PROBLEMA DE UNA FUNCIONALIDAD DEL SERVICIO
AVERIAS EN PRODUCTOS COMPLEMENTARIOS
Edición 1.8
Página 64 de 155
Incomunicación Parcial Sede (extensiones o rangos)

Incomunicación TOTAL VOZ SEDE
Incomunicación TOTAL VOZ RAI
VOZIP. Avería en Línea Móvil
VOZIP. Avería en Buzón de Voz (excepto CentrexIP)
VOZIP. Avería en Agenda de Contactos
VOZIP. Avería en Call Center
VOZIP. Avería en Comunicaciones Unificadas (CCUU)
VOZIP. Avería en Grabador
VOZIP. Avería en Grupo de Salto
VOZIP. Avería en Operadora Automática
VOZIP. Avería en Tarificador
VOZIP. Avería en Llamadas (Cortes ruido voz metálica)
Ibercom IP, Corporate IP Alojado, e
VOZIP. Avería en Teléfono (Funcionamiento erróneo)
Ibercom IP en Red
VOZIP. Avería en Teléfono (No enciende)
VOZIP. Avería en otras Facilidades
VOZIP. Incomunicación total de extensiones
VOZIP. Otros problemas en servicio de voz
VOZIP. Avería en Operadora PC - Aplicación Recepcionista
VOZIP. Incomunicación varias extensiones
VOZIP. Incomunicación entre sedes
VOZIP. Incomunicación > 50% extensiones
Revisión de tareas y configuración
Soporte primer uso
AVERIA DEL RESPALDO – no aplica a LITE --
INCOMUNICACION ENTRE SUBSEDES
Gateway para NGN PBX-IP, Gateway INCOMUNICACION PARCIAL (FUNCIONANDO POR BACKUP) – no aplica a LITE --
para NGN PBX-RDSI INCOMUNICACION TOTAL (NO TIENE BACKUP)
INCOMUNICACIÓN TOTAL (PRINCIPAL y BACKUP CAIDO) – no aplica a LITE --
VOZIP. Avería en Llamadas (Cortes ruido voz metálica)
AVERIA DEL RESPALDO
INCOMUNICACION ENTRE SUBSEDES
MacroLAN, VPN IP, DataInternet, INCOMUNICACION PARCIAL (FUNCIONANDO POR BACKUP)
FlexWAN y RPV Internacional INCOMUNICACION TOTAL (NO TIENE BACKUP)
INCOMUNICACIÓN TOTAL (PRINCIPAL y BACKUP CAIDO)
LENTITUD O CORTES INTERMITENTES
Específico para Datainternet Problema en Resolución DNS (no aplica a LITE)
Específico para FlexWAN Fallo Plataforma Central
Específico para RPV Internacional Provisión RPV Internacional
Edición 1.8
Página 65 de 155
SILAN: Problema en la red WiFi - Problema de autenticación de usuarios

SILAN: Problema en la red WIFI - Incomunicado Total
SILAN: Problema en la red WIFI - Incomunicado Parcial
SILAN: Problema en la red Cableada - Incomunicado Total Voz
SILAN: Problema en la red Cableada - Incomunicado Total Datos / Voz
SILAN
SILAN: Problema en la red Cableada - Incomunicado Total Datos
SILAN: Problema en la red Cableada - Incomunicado Parcial Voz
SILAN: Problema en la red Cableada - Incomunicado Parcial Datos / Voz
SILAN: Problema en la red Cableada - Incomunicado Parcial Datos
SILAN: Equipo no enciende
FLEXSITE: Equipo no enciende
FLEXSITE: Red WiFi - Problema de autenticación de usuarios
FLEXSITE: Red WIFI - Incomunicado Total
FLEXSITE: Red WIFI - Incomunicado Parcial
FLEXSITE: Red Cableada - Incomunicado Total Voz
FLEXSITE
FLEXSITE: Red Cableada - Incomunicado Total Datos/Voz
FLEXSITE: Red Cableada - Incomunicado Total Datos
FLEXSITE: Red Cableada - Incomunicado Parcial Voz
FLEXSITE: Red Cableada - Incomunicado Parcial Datos/Voz
FLEXSITE: Red Cableada - Incomunicado Parcial Datos
FLEXSITE: Problema con el Portal ARUBA CENTRAL
En casos excepcionales donde el centro no pueda adaptar la casuística a estos síntomas, se deberá
adoptar el que más encaje, y reportarlo vía FARO al responsable del servicio CEx para su evaluación
como se indica a continuación:
Edición 1.8
Página 66 de 155
Uno de los problemas principales a identificar claramente en servicios MacroLAN, VPN IP,
DataInternet (incluidas funcionalidades), FlexWAN y RPV Internacional es si un Cliente está
incomunicado, ya que estamos afectando a su negocio y posiblemente provocándole pérdidas
importantes. En estos casos revisaremos:
Incidencias en sedes con respaldo donde el respaldo no se haya activado: se presenta una
incomunicación total de servicio. En este caso se abrirán dos incidencias, una sobre el circuito
principal con el Síntoma “Incomunicación total (principal y backup caído)” y otra sobre el respaldo
con el Síntoma “Avería en el respaldo” y se gestionarán en paralelo, documentando el escenario
adecuadamente en el sistema corporativo. La modalidad DataInternet Lite no aplicaría en este punto,
ya que este servicio carece de la modalidad de backup.
Incidencias en sedes con respaldo donde el respaldo sí se haya activado: En este caso,
donde el cliente no está realmente incomunicado pues dispone de respaldo, se procederá a
documentarlo adecuadamente en la incidencia, indicando los datos del respaldo y reflejando las
pruebas que demuestran su funcionamiento, asegurando su conocimiento para el resto de la
organización e indicando el Síntoma: “Incomunicación parcial (funcionando por backup)”. La
modalidad DataInternet Lite no aplicaría en este punto, ya que este servicio carece de la modalidad
de backup.
Edición 1.8
Página 67 de 155
Incidencias en sedes sin respaldo: En los casos en los que no exista respaldo se presenta
también una incomunicación total del servicio, se abrirá una incidencia con el Síntoma
“Incomunicación total (no tiene backup)” y se documentará que no existe respaldo.
Incidencias en circuitos de backup o respaldo: No procede marcar como incomunicación una

incidencia asociada al circuito de backup, sino que en este caso procede el síntoma “Avería en
respaldo”, ya que la marca de incomunicación sólo hace referencia al circuito principal y no al backup
según se detalla en las guías operativas de GDIA. La modalidad DataInternet Lite no aplicaría en este
punto, ya que este servicio carece de la modalidad de backup.
Además, se amplía a continuación la información de algunos de los síntomas.
• Proactiva: Cuando se registra una incidencia en GDIA de forma automática, se reflejará en

el campo SINTOMA como incidencia PROACTIVA. Ninguna incidencia debe progresar a la fase
de diagnóstico con este síntoma, debe cambiarse para reflejar el síntoma real durante la vida
de la incidencia.
• Incomunicación Total: descrito en el apartado anterior, este síntoma se presenta cuando la

totalidad del servicio y gestión está incomunicado. El cliente no puede trabajar y no se
dispone de gestión de los equipos implicados en dicho servicio.
• Lentitud, falta de prestaciones y cortes de servicio: En este caso tanto el servicio como la
gestión están operativas, aunque o bien se presentan con lentitud o con cortes con una
ocurrencia relativamente frecuente, o el cliente considera que el servicio no alcanza las
prestaciones contratadas.
• Falta de operatividad parcial o total del servicio: Este “prediagnóstico” se utilizará cuando
no se presentan cortes en el circuito de acceso, pero a pesar de ello el cliente no puede
trabajar o trabaja de manera deficiente. Se presentarán casos en los que el equipo a pesar de
no estar dando servicio es gestionable.
• Avería en circuito funcionando por Backup: Se utilizará en aquellos casos en que el

principal esté caído y el respaldo esté activo. La modalidad DataInternet Lite no aplicaría en
este punto, ya que este servicio carece de la modalidad de backup.
• Incomunicación entre Subsedes: Se utilizará en aquellos casos en que, no habiendo

incomunicación, esto es, el circuito no está caído, o bien se accede por gestión, una sede
determinada esté incomunicada con las otras. En este caso no procederá la marca de
incomunicado. Es importante identificar entre qué sedes se produce la incomunicación
(origen y destino).
• Soporte primer uso: Se utilizará en los tickets registrados para que el CEx revise la
conectividad o haga pruebas conjuntas con el CdS o el instalador durante la provisión de los
servicios de voz: Ibercom, Ibercom Ip o Centrex Ip.
Edición 1.8
Página 68 de 155
• Revisión de tareas y configuración: Se utilizará en los tickets registrados por el CdS Ibercom
o Centrex en los que solicita al CEx que revise la configuración del servicio de conectividad
previo a la instalación del servicio de voz.
6.1.1 PROCEDIMIENTO DE CONTINGENCIA GDIA Y SAC VANTIVE
El procedimiento a seguir ante una caída de GDIA y/o SAC VANTIVE está recogido en la guía operativa
de GDIA, en el apartado “ACTUACIÓN EN CASO DE CONTINGENCIA GDIA”, donde se explica cómo
actuar ante la indisponibilidad o caída de estos sistemas.
De forma resumida este sería el procedimiento a seguir, aunque el detalle completo se debe
consultar en la citada guía:
 Ante una caída de GDIA:
o Se deben atender las incidencias desde SAC VANTIVE.

o Pararse el envío de alarmas proactivas de WOCU a ASTRO.
o Solo abrir SIRIO de las incidencias urgentes y con diagnóstico claro.
o Para los servicios de voz insertar los datos del Formateador.
o Para los servicios de datos, se deben insertar las pruebas del Orquestador, y cuando abramos
boletín SIRIO se debe enviar correo a TE_CdSDatosMantenimiento
cdsdatos.mantenimiento@telefonica.com.
o En caso de sustitución de EDC, cuando CdS responda a nuestro correo informado que ha
enviado SIRIO, enviaremos correo a Zeleris repuestosedc@zeleris.com.
o Si no se informa el SLA se tratará como SLA estándar.
o El Protocolo permanecerá vigente hasta que se reciba el comunicado de final de
contingencia.
o Hay un teléfono para soporte sobre CONTINGENCIA de sistema GDIA y/o evolución de la
Incidencia del SISTEMA.
o Hay un listado de Contactos y Escalados.
 Ante una caída de SAC VANTIVE:

En este caso el interfaz SAC GDIA también se vería afectado debido a la caída de SAC VANTIVE, por lo
cual no dispondríamos de ninguno de los dos sistemas para efectuar el registro y tratamiento de las
incidencias. En esta situación aplicaría el mismo procedimiento ante la caída de GDIA, pero con la
siguiente diferencia:
o Debido a que no se podrían atender las incidencias desde SAC VANTIVE, la transferencia a los
Centros de Servicio se debe realizar por correo a los buzones de contacto o escalado de cada uno. En
el caso de los servicios de datos se debe realizar al buzón TE_CdSDatosMantenimiento
cdsdatos.mantenimiento@telefonica.com.
SERVICIO Solo para los casos

PROCEDIMIENTO
siguientes
Edición 1.8
Página 69 de 155
SERVICIOS
Solo Se enviará un correo al Centro de Servicio de Conectividad
CONECTIVIDAD
Incomunicaciones “TE_CdSDatosMantenimiento <cdsdatos.mantenimiento@telefonica.com>”
Totales aportando los datos necesarios. Al no poderse enlazar con los sistemas y no
poderse pegar la ficha ética, se deben incluir:
 Cliente
 Identificativo del circuito (teléfono / administrativo)
 Nemónico y modelo del equipo, así como despiece en

caso de que fuera necesario
 Servicio
 Descripción de la incidencia
 Datos de contacto del Centro de Gestión
 Datos de contacto del Cliente
Una vez enviado el correo con los datos, se procederá a llamar al CS

(900125365 opc. 2) para notificarles del envío del correo y aportar si
procediera información relevante.
SERVIVIOS Solo Enviar al buzón: escaladosct.servicioscorporativosibercom@telefonica.com y

IBERCOM y SRC Incomunicaciones llamada al 900211110 opc.3
Totales
SERVICIOS RIS Solo Enviar a EMP-CSS-CAS novecientos@telefonica.com y llamada al 90020007

Incomunicaciones
Totales
MASIVAS Todas Se contactará con el Command Center (900 42 42 00) para la coordinación de
este.
6.1.2 INCIDENCIAS LOCALES
Ante determinadas situaciones se podrá marcar una incidencia en local por considerarse que no
afecta al servicio o bien se demora por casusas originadas por el cliente. El marcado de cualquier
incidencia en local se realiza desde el Interfaz SAC-GDIA con el check del cuadro de tratamiento para
todas las averías.
Desde el interfaz SAC-GDIA se podrá pasar a Local todas las incidencias independientemente del
origen de la apertura.
Edición 1.8
Página 70 de 155
Siempre que se marque una incidencia en Local, es necesario que en “Comentarios” se indiquen los
motivos que justifiquen su paso a Local. Además, es importante tener en cuenta que las incidencias
locales no saldrán en los informes IRIS/PIP.
A continuación, se detallan los casos en los que se puede registrar o marcar una incidencia como
Local:
 Si el cliente demora la atención de la avería en un tiempo superior a 48 horas laborables (se

excluye el fin de semana):
Se recogen bajo este caso las circunstancias que impidan tratar la incidencia transcurrido el
plazo de las 48 horas laborables siguientes al evento asociado a la incidencia por los siguientes
motivos:
o Incidencia identificada en una sede de horario reducido, en obras o cerrada por cualquier
motivo imputable a cliente, donde sea necesario realizar comprobaciones in situ
(ejemplos, reinicio manual del EDC, verificación de cableado) o la asistencia de un técnico
de campo (ejemplos; cambio de EDC, revisión de Conversor de Medios).
o Incidencia donde el equipamiento es propiedad de cliente y en el tratamiento de la
misma se identifica la necesidad de aportar pruebas o trazas por parte del cliente para
confirmar la conectividad entre el equipamiento de Telefónica y el equipamiento de
cliente (por ejemplo; centralitas propias de cliente, Firewalls no gestionados por
Telefónica), donde no se han aportado dichas pruebas.
o Incidencia donde el CEx/CGE no consigue contactar con el cliente para realizar las
verificaciones del correcto estado del equipamiento (ejemplos; EDC conectado a la
corriente eléctrica, posibilidad de reinicio manual del mismo, verificación de cableado).
La incidencia no podrá marcarse en local hasta que haya finalizado el periodo de 48 horas
laborables y se haya verificado que estamos ante alguna de las situaciones anteriormente
descritas y no hay alternativas de solución que permitan evitarlas. Es necesario confirmar y
registrar el contacto de cliente que pospone la resolución de la incidencia, y el motivo.
En el supuesto de no conseguir contactar con el interlocutor de cliente para la incidencia
deberemos actuar del siguiente modo, intentando siempre conseguirlo antes de que se
cumplan las 48 primeras horas laborables desde la presencia del evento que originó la
incidencia. Si se cumple este plazo sin conseguir contactar con el interlocutor de cliente para la
incidencia, debe marcarse la incidencia como local:
o Modalidades de gestión estándar (CEx y CEx Avanzado). El contacto registrado en la

apertura automática del ticket es reflejo de la información presente en TW, por tanto, si
no conseguimos localizar a dicho contacto deberemos reportarlo al asesor personal del
cliente y verificar con éste el contacto de cliente para la incidencia.
o Modalidades de gestión personalizada (CEx Premium, CEx Premium Plus y CGE). En el
supuesto de no conseguir contactar con el interlocutor de cliente para la incidencia,
deberemos reportarlo al interlocutor autorizado de cliente y verificar con éste el
contacto de cliente para la incidencia.
Edición 1.8
Página 71 de 155
 Si la avería no afecta al servicio, y se trata únicamente de los siguientes casos:

o Ventiladores del EDC
o Fuentes de alimentación redundantes del EDC
o Ruido del EDC
o Incidencias registradas para dejar constancia de las actividades de mantenimiento
preventivo y correctivo, entre ellas las pruebas de backup, actualización de certificados
de iAP, actualización de software, y se hará según lo definido para cada una de ellas.
El marcado de una incidencia en local se realizará de la siguiente forma:
 GDIA: marcar directamente el check “Local” del menú “Tratamiento” de la incidencia que
cumple con los criterios de paso a local.
Siempre que se marque una incidencia en Local, es necesario que en Comentarios se indiquen los
motivos que justifiquen su paso a Local, y se incluyan los datos de contacto de la persona
responsable de cliente que pospone la resolución de la avería, si es el caso.
Una vez desaparecen los impedimentos relativos a la sede o las verificaciones con cliente descritas
anteriormente y si se verifica que la incidencia ha quedado solucionada siendo el motivo que la
originó el diagnosticado inicialmente, se cerrará como local con el “Responsable”, “Localización” y
“Causa” que corresponda. En caso contrario, es decir, una vez desaparecen los impedimentos
relativos a la sede o las verificaciones con cliente descritas anteriormente y si no se ha resuelto la
incidencia o el diagnóstico inicial es erróneo, se cerrará esta incidencia local con el “Responsable =
Cliente”, “Localización = Domicilio/Infraestructura/Servicios de cliente” y “Causa = Cliente demora la
atención de la incidencia”, y se abrirá una nueva con la misma caracterización que la primera, es
decir mismo identificador, servicio, síntoma y descripción, citando el número de la incidencia inicial
de la que procede.
6.1.3 INCIDENCIAS ANULADAS
Siempre que se anule una incidencia es necesario documentar las razones por las que se ha anulado.
Únicamente se deberán anular incidencias en los siguientes casos:
• Incidencias Duplicadas: Cuando existen 2 incidencias simultáneas sobre el mismo circuito

para tratar el mismo problema. Se anulará la incidencia que se haya abierto más tarde.
• Incidencias con datos erróneos: Si en el momento de abrir la incidencia se registra

erróneamente alguno de estos datos: NIF/CIF, Identificador, Valor y la herramienta de ticketing no
permite editarlos se deberán identificar los datos correctos y abrir una nueva incidencia con dichos
datos.
• Bajas: Si al hablar con el cliente nos indica que el circuito afectado es una baja y disponemos
de pedido SGC/Logos de esta, deberá anularse la incidencia, será necesario indicar dicho pedido en la
incidencia, e incidentar el pedido para parar la baja y recuperar el circuito. En los casos en los que no
tengamos pedido SGC/Logos asociado no podrá anularse la incidencia, lo dejaremos debidamente
Edición 1.8
Página 72 de 155
documentado, informaremos al área comercial y cerraremos la incidencia como: Cliente – EDC

Router/Frad/TimeStep/Centralita – Mala Operación.
• Incidencias Mal Abiertas por TEDI (Portal Autogestión): En el caso de las incidencias que el
cliente abra erróneamente desde el portal que sustituye a eAtencion. La vía de entrada de estas
incidencias en GDIA será “Portal Mi Gestión Digital (Web)”. El procedimiento es llamar a cliente para
notificarle que anulamos su incidencia por estar mal abierta, y le explicamos el motivo. Le
indicaremos que si tiene dudas sobre el uso del portal se ponga en contacto con su asesor personal.
• Incidencias Mal Abiertas por el CGC: Si los campos erróneos son modificables, el CEx deberá
actualizar la información, en caso contrario el CGC es el responsable de la anulación de estas.
Incidencias con datos erróneos que no son editables, un servicio no gestionado, o sobre un elemento
que no existe. El procedimiento establecido con dichas áreas es el siguiente:
El Centro de Excelencia devuelve la incidencia al buzón que ha originado la incidencia. Para

verificarlo:
Desde GDIA: Es posible consultar el usuario y buzón de apertura desde la “bitácora” del ticket y
en los “listados” de movimientos sobre el mismo.
Si la matrícula que ha registrado el ticket pertenece a un área del CGC, el Centro de Excelencia
manda un correo al asesor personal asesorpersonal@telefonica.es, con el siguiente formato en
el asunto del mensaje: CIF: xxxxxxxxx Incidencia abierta errónea GDIA. Hay que indicar
claramente el motivo de la devolución.
Si la matrícula que ha registrado el ticket pertenece al área Hosting y ASP N1 Admin Servicios,
se devuelve la incidencia indicando el motivo de la devolución.
El personal de esta área es proactivo por lo que detectará la devolución de la incidencia y

actuará sobre la misma. En paralelo se mandará un correo al buzón nn1das@telefonica.es, para
llevar un control de las incidencias devueltas.
• Incidencias Mal Abiertas por el Service Desk (SD) de Digital Workplace (DWP): Si el CEx recibe
un ticket abierto de forma incorrecta, si los campos erróneos son modificables, los modificará, en
caso contrario, devolverá la incidencia al grupo “Host Aspn1 Adm Serv Host” del SD para que la anule
y la reabra correctamente. En el caso de que se necesite información adicional el CEx se podrá poner
en contacto con el SD en:
Nombre Correo Teléfono

Soporte SD dstsol.ctpt@telefonica.com 900102230 opción 2
Edición 1.8
Página 73 de 155
• Desde GDIA se puede realizar el marcado a local sin necesidad de cerrar la incidencia anterior
en el caso de incidencias abiertas por otra Área.
6.1.4 INCIDENCIAS MASIVAS
Si se detecta un aumento elevado de alarmas en una zona concreta, y se estima que puede tratarse
de una incidencia masiva, se procederá de la siguiente forma:
Primero, se intentará acceder a varios EDCs para comprobar en red que se trata de una avería
masiva real y no de un fallo en la herramienta de monitorización que está reportando averías falsas.
Una vez que se ha comprobado que realmente se trata de una incidencia masiva se
comprobará en la web de Servicios Afectados que no se trata de un BTP (Boletín de Trabajo
Programado).
Se dispone de una herramienta en CNCE en la que, dependiendo de (tramo horario + provincia + nº

incidencias) activa un proceso para determinar 1 posible masiva de servicios de datos en una
provincia.
Esta posible incidencia masiva se contrasta con SOR, y confirma la incidencia masiva, se informa a
todas las unidades que están suscritos al servicio de alarmas en la página WEB.
https://cnce.es.telefonica/web/cse/cse_fuentes/cse_f_gestion/documentacion_plantillas.php
Si en dicha web no se hubiera registrado ninguna incidencia masiva el CEX se pondrá en contacto con
el CNCE según el procedimiento BTO-OYM-GES-GUI-58021 Guía de PROCEDIMIENTO INCIDENCIAS
CRITICAS Y MASIVAS POSTVENTA EMPRESAS, siendo el Command Center el responsable de analizar
por qué un circuito afectado por una masiva no ha sido marcado como tal.
Edición 1.8
Página 74 de 155
Cuando el CNCE confirma que se trata de una incidencia masiva la publica en la web del CNCE, a
partir de ese momento, GDIA marcará en cada ticket abierto sobre un circuito afectado por una
masiva el código de la “INC-XXXX” que aplique en cada caso. Aclarar en este punto que GDIA no
enraíza incidencias, simplemente muestra la información que genera MCE/SAFI.
Con todo esto conseguimos que no sea necesario repetir la información en todas las incidencias
afectadas por la misma masiva, sino que basta con informar en la incidencia marcada como cabecera
de la masiva.
6.1.5 ACCESOS Y RESPALDOS MÓVILES VPN IP
El registro de incidencias de Accesos y Respaldos Móviles desde GDIA se realizará con el identificativo
del acceso buscando por los parámetros “Administrativo” o “Teléfono” ficticio que lo identifica en
sistemas, quedando registrado finalmente por el valor del Administrativo del acceso.
Se debe comprobar si la ubicación real coincide con la que está en LOGOS-PT, y en caso de no
coincidir, se deberá orientar al cliente para que desplace el equipo averiado al domicilio que aparece
en LOGOS-PT. En caso de que el cliente no pueda desplazar el equipo al domicilio de LOGOS-PT,
debemos confirmar con cliente si éste será el domicilio definitivo, y si es así se debe pedir a cliente
que solicite su regularización vía comercial. En cualquier caso, se debe abrir el ticket en GDIA por el
domicilio de la ubicación real del equipo.
Adicionalmente, el interfaz solicitará la cumplimentación del “Teléfono de la SIM” como parámetro

secundario correspondiéndose con el MSISDN de 9 dígitos (sin introducir el prefijo del país).
En caso de apertura de incidencia en contingencia ante caída de GDIA, se debe abrir directamente
desde VANTIVE, y se abriría por el administrativo del circuito, especificando en el parámetro
secundario el MSISDN de la tarjeta SIM del equipo para ese acceso, y modificando el Domicilio y
Provincia dónde está ubicado en ese instante el equipo.
6.1.6 INCIDENCIAS CON UN SEGUNDO OPERADOR (SOLUCIONES ESPECIALES)
En el caso de que el CEX/CGE gestione una Solución Especial (necesaria VTO CEx Positiva) de accesos
de un segundo operador, la incidencia se registrará manualmente en GDIA para su seguimiento y
actualización
Si la VTO CEx tramitada incluye que el CEx/CGE realice supervisión del tráfico o monitorización del
segundo operador, bien con herramienta propia o del cliente las incidencias se abrirán
proactivamente.
Si la VTO CEx tramitada no incluye monitorización de los accesos del segundo operador, la incidencia
será comunicada por el cliente por las vías habituales.
El registro de la incidencia en GDIA se hará con el Tipo de Servicio SOLUCIÓN ESPECIAL.
Edición 1.8
Página 75 de 155
6.1.7 INCIDENCIAS DEL SERVICIO CGE MULTIOPERADOR
Esta operativa sólo aplica a CGE porque el servicio MULTIOPERADOR no está integrado en ninguna
modalidad de atención CEx
En el caso de que el cliente, además de una Solución Especial de gestión de accesos de un segundo
operador (necesaria VTO CEx Positiva), haya contratado el servicio MULTIOPERADOR gestionado
desde CGE, éste deberá registrar las incidencias/peticiones manualmente en GDIA para su
seguimiento y actualización ya que, aunque sea de forma delegada para el cliente, el CGE realiza
labores de coordinador de las comunicaciones con diferentes operadores
Si el Cotizador CGE tramitado incluye el elemento “Herramienta de Supervisión” se deberán registrar

proactivamente las incidencias de los accesos segundo operador.
Si el Cotizador CGE tramitado no incluye el elemento “Herramienta de Supervisión” la incidencia será

comunicada por el cliente por las vías habituales
El registro de la incidencia en GDIA se hará con el Tipo de Servicio SOLUCIONES ESPECIALES -

MULTIOPERADOR.
La identificación del elemento se realiza con el NAD de la línea física del enlace de Telefónica, aunque
éste se encuentre operativo, es únicamente a efectos de identificación del elemento de
configuración.
Si el enlace de Telefónica también estuviera en avería, se abrirá otro ticket GDIA siguiendo el
procedimiento habitual.
La tipología y diagnósticos del Tipo de Servicio SOLUCIONES ESPECIALES -MULTIOPERADOR son los
mismos que los del servicio Macrolan.
6.2 A5 - DIAGNÓSTICO DE INCIDENCIAS
El objetivo de esta fase es, una vez registrada la incidencia, obtener un diagnóstico apoyándonos en
los síntomas que se manifiesten o los informados por el cliente, documentarlo en el sistema de
ticketing e informar al Cliente de dicho diagnóstico, reflejando además la realización de este contacto
en la herramienta de ticketing del servicio tal como se indica en el ANEXO 2: PLAN DE
COMUNICACION A CLIENTE.
Si durante esta fase se identifica que la tipificación de facilidad era errónea, es decir, que finalmente
el problema está en alguna de las facilidades disponibles o no lo está y se identificó inicialmente que
sí, debemos corregir dicha tipificación.
Para todos los servicios, si por algún motivo el CEx/CGE no tuviese la posibilidad de realizar el
diagnóstico de red, debe derivarlo al Centro de Servicio (CdS) mediante transferencia por las vías
habilitadas.
Edición 1.8
Página 76 de 155
Para realizar el Diagnóstico es obligatorio utilizar la herramienta “Orquestador” para los Servicios de
Datos y “Formateador” para los servicios de voz, además de realizar todas las pruebas indicadas en
las guías de cada uno de los servicios hasta estar seguros de que el diagnóstico obtenido es el
correcto. Para esto debemos acceder a los elementos que componen el servicio, ayudarnos de las
aplicaciones de gestión y diagnóstico, e incluso de ser necesario, contactar nuevamente con el cliente
para recabar la información o actuaciones por su parte que fueran necesarias con el objetivo de
identificar el elemento o elementos probables, que están provocando la avería y actuar sobre ellos.
Un tema para tener en cuenta durante esta etapa es que se deberá verificar si se ha producido la
entrada de varias incidencias a la vez en la misma provincia ya que es posible que estemos ante una
incidencia masiva.
El primer diagnóstico debe quedar registrado en el sistema de ticketing en la primera hora de vida de
la incidencia desde el momento de registro.
Como ejemplo se muestran algunos síntomas típicos y algunos de sus diagnósticos posibles:
Incomunicación Total:
Circuito de acceso cortado (Red)
Circuito mal configurado o dado de baja (Red)
Problema en instalación del acceso (Circuito)
EDC averiado (EDC)
Problema de configuración en EDC (EDC)
Lentitud:
Perdida de tráfico en medio físico (Red)
Perdida de tráfico a nivel IP (Red)
Problema de configuración en Red (Red)
Saturación de tráfico (EDC/Red)
Saturación de recursos en elementos del servicio (EDC/Red)
Cortes de Servicio:
Cortes en circuito de acceso (Circuito)
Edición 1.8
Página 77 de 155
Problema en equipo de Red (Red)
Falta de operatividad parcial o total del servicio:
Problema de configuración en Red (Red)
La información más relevante que consultar y/o completar en esta fase es la siguiente:
Datos del circuito afectado: Deberán indicarse aquellos datos importantes que será
necesario consultar durante la vida de la incidencia tales como: administrativo, ip de gestión,
nemónico, contacto de cliente, etc.
Breve descripción de la avería: deberá quedar reflejado cómo se ha detectado la avería, cuál
es la causa origen que ha generado la misma, …
Comprobar si tiene o no respaldo: Se deberá indicar si hay o no respaldo contratado. En caso

afirmativo se deberán incluir los datos de este indicando si está o no operativo, así como las pruebas
realizadas para comprobar su correcto funcionamiento.
Comprobar si es repetida: En caso de ser una incidencia repetida, se debe aplicar lo indicado
en el apartado “A11-Gestión de Problemas”.
Verificación afectación masiva o BTP: se deberá indicar si está afectada por una masiva o
BTP.
Pruebas y acciones realizadas: Durante la vida de la incidencia será necesario documentar

las pruebas o acciones que se vayan realizando.
Dependiendo del diagnóstico se deberán realizar las acciones pertinentes bien sea para resolver la
incidencia, o bien para transferirla de cara a su resolución por otra área.
Cuando se confirme si hay incomunicación de la sede de cliente, se debe documentar dicha

incomunicación en el ticket de la incidencia, al igual que si durante la vida de la incidencia esto
cambia y se recupera la conectividad, se debe quitar la incomunicación. Se debe documentar el inicio
y fin de cada incomunicación que se produzca a lo largo de la vida de la incidencia, con el objetivo de
que el tiempo de incomunicación documentado en el sistema de ticketing se corresponde al máximo
con el tiempo de incomunicación real.
Si se determina que el problema no está en los elementos de los servicios de conectividad sino en
algún elemento de los servicios de TI, se debe proceder según las indicaciones de su correspondiente
guía operativa.
Edición 1.8
Página 78 de 155
6.2.1 ACCESOS Y RESPALDOS 3G/4G/5G (VPN IP + DATAINTERNET)
Durante la fase de diagnóstico debe realizar una serie de comprobaciones previas, además de las del
Orquestador, para tratar de determinar si se trata de un problema en la propia red móvil de acceso o
en el servicio VPN IP y/o Datainternet.
Para ello se realizarán las siguientes acciones (ver diagrama adjunto).
Si tras el reinicio del EDC no se recupera conectividad por el acceso o backup móvil, hay que intentar
verificar si hay cobertura móvil Movistar en la misma sala donde esté ubicado el router y/o la antena.
Si tras las pruebas con cliente, se detecta que no hay cobertura o no se puede navegar, el Centro de
Excelencia llamará al CAT Móvil: 1489 +700700700 y registrará Actuación externa a CGC Móviles,
indicando el número de eGRIM/REC.
Para que el CAT Móvil pueda identificar correctamente el nº teléfono afectado es muy importante
que les facilitemos el MSISDN o el ICC de la tarjeta SIM.
En conferencia a 3 con el cliente, se realizarán las comprobaciones necesarias para continuar con la
resolución de la incidencia.
En aquellos casos en los que el CAT Móvil sea capaz de resolver el problema en el momento, el
Centro de Excelencia realizará las comprobaciones necesarias. Una vez confirmado el correcto
funcionamiento con el cliente, procederá al cierre del ticket.
Edición 1.8
Página 79 de 155
Si durante las pruebas el CAT Móvil detecta que sólo tienen de alta el APN de instalación, y NO el
APN de servicio, se trata de una incidencia de provisión que el CAT no puede resolver. Se cambiará
en ticket de la incidencia a Provisión y se tratará con el área correspondiente.
Edición 1.8
Página 80 de 155
6.3 A6 - TRANSFERENCIA
El objetivo de esta fase es el de encaminar adecuadamente las incidencias o peticiones que se deban
resolver en otras áreas tras realizar las pruebas de diagnóstico, es decir, proceder a la transferencia
de la incidencia al grupo correspondiente para su tratamiento a través de la vía establecida para ello.
Dependiendo del servicio la vía de transferencia puede ser un sistema (boletín SIRIO/WINEST
generado desde GDIA, REMEDY ON DEMAND para servicios internacionales), un mail a un buzón
genérico, u otras según lo establecido en las guías de los servicios. En la siguiente tabla podemos ver
un resumen:
LINEA
SERVICIO TICKETING TRANSFERENCIA
ACTIVIDAD
GDIA SIRIO (desde GDIA), EGRIM/REC (solo

DataInternet para red móvil de los Accesos y
Respaldos Móviles)
Circuito punto a punto internacional GDIA RoD, SIRIO, o SAM 1002/1489
Circuitos punto a punto (nacional) GDIA SIRIO (desde GDIA)
Facilidad SILAN (TIC+ LAN) GDIA SIRIO (desde GDIA)
MacroLAN GDIA SIRIO (desde GDIA)
MetroLAN GDIA SIRIO (desde GDIA)

VPN IP para red móvil de los Accesos y
Respaldos Móviles)
DATOS
GDIA RoD (Distribuidora), SIRIO
VPN IP Internacional (RPV Internacional)
(Prestadora)
GDIA SIRIO (desde GDIA), SAM 1002/1489

flexWAN
(Residencial)
Optimización de Aplicaciones en RPVs
InterLAN GDIA SIRIO (desde GDIA)
Frame Relay GDIA SIRIO (desde GDIA)
Nodo de red GDIA SIRIO (desde GDIA)
Interconexiones de Fibra Directa GDIA Llamada o correo al CNSRPC
Cloud Connect GDIA RoD
LINEA SERVICIO TICKETING TRANSFERENCIA
Edición 1.8
Página 81 de 155
ACTIVIDAD
SIRIO (desde GDIA), EGRIM/REC (solo

Corporate IP Alojado GDIA para la red móvil o Corporativo
Móvil)
SIRIO (desde GDIA), EGRIM/REC (solo

Ibercom (Tradicional, IP) GDIA IIP para la red móvil o Corporativo
Móvil)

Centrex IP (Ibercom IP en Red, MFEP,
para la red móvil o Corporativo
VOZ FlexUser)
Móvil)
Acceso Primario Virtual (Ca NGN, GW GDIA SIRIO (desde GDIA)

NGN)
Acceso único IP (AuIP, GW NGN) GDIA SIRIO (desde GDIA)
Accesos básicos RDSI GDIA SIRIO (desde GDIA)
Accesos primarios RDSI GDIA SIRIO (desde GDIA)
Antes de ejecutar la transferencia es imprescindible:
Comprobar que los datos aportados sobre el ticket son los correctos, como por ejemplo el
administrativo del circuito o identificador del elemento, la Manifestación o el Diagnóstico.
En caso de ser necesario acudir al domicilio de cliente, haber contactado con el cliente
confirmando el horario de atención, su disponibilidad en las siguientes 48 horas, persona y teléfono
de contacto del cliente-sede, además de trasladar esta información junto con las pruebas realizadas
(XLAN, Orquestador, Formateador) en todos los casos. Si no se cumple lo anterior y/o el cliente no
tiene disponibilidad en las siguientes 48 horas, no se debe abrir boletín SIRIO.
Si se requiere añadir información adicional a un boletín SIRIO/WINEST, desde GDIA se debe

registrar en el campo de Comentarios y marcar el check para que se refleje esa información en GDIA
y en SIRIO. Si no se hace esto, la información se pierde. Finalmente, debemos asegurarnos de que se
ha enviado y generado correctamente el número de SIRIO.
Para los casos donde la transferencia se realice para solicitar un cambio de equipo o
elemento, se debe revisar que el equipo o elemento que se llevará a domicilio de cliente es correcto
en el siguiente enlace, que proporciona acceso a la ventana general de la gestión de repuestos desde
donde podemos usar diferentes filtros (Fases, Estados, Territorios, Provincias, centro, etc…), y
contrastar el código logístico en BTO-LOG-MAT-CAT-51944 Referencia Suministrador LORCET, En
caso de que el código de LOGOS-PT no se corresponda con el de LORCET, se debe coger el que lo
sustituye y modificarlo en LOGOS-PT.
http://10.57.7.179:8080/Gdia_Repuestos/listados/listaRepuestosResumen.xhtml?
windowId=e3c&codigoEmpresa=TELEF0010001805
Edición 1.8
Página 82 de 155
Además, tanto para los servicios de datos y como de voz, se debe hacer los establecido en la
guía del sistema de ticketing o en la guía operativa de cada servicio.
Relacionado con los boletines SIRIO/WINEST, el Centro de Servicio franqueará todos los boletines
SIRIO que no estén bien diagnosticados según el Orquestador o Formateador, o que no contengan la
documentación y resultados de todas las pruebas realizadas.
En caso de que se confirme que la incidencia está relacionada con una incidencia masiva y no nos
deje abrir boletín SIRIO, se deberá proceder según lo establecido en el apartado “6.1.4 INCIDENCIAS
MASIVAS”.
Debido a que hay CGE que no tienen horario 7x24, los CEx (Estándar) 7x24 se hacen cargo de la
gestión de las incidencias fuera de horario de estos CGE.
 Si el cliente fuera de horario del CGE quiere reportar una incidencia, debe reportarla a
CGC/1002 quien procederá al registro en SAC/GDIA.
 GDIA aplicará un algoritmo cotejando la información del horario del CGE NO 7*24 en LOGOS
PT; así como el CEx de desborde. Durante el tramo que dure dicho desborde, GDIA alojará
puntualmente las incidencias del CGE NO 7*24 desbordado en el contenedor GDIA del CEX de
desborde.
 Finalizado el horario de desborde, automáticamente dichas incidencias serán visibles

únicamente en el contenedor GDIA del CGE.
 Si el CGE no 24*7 contrata gestión premium FFHH podrá llamar al CEx directamente para
reportar incidencias/peticiones y serán ellos quien abran el ticket en GDIA.
 Por tanto, es imprescindible una correcta calidad del dato en LOGOS PT para un
funcionamiento óptimo de la asignación.
6.3.1 ACCESOS Y RESPALDOS 3G/4G/5G VPN IP + DATAINTERNET
Una vez identificado si el problema está en la parte móvil o en el EDC o la SIM, se debe proceder
como se indica a continuación.
PROBLEMAS DETECTADOS EN EL ACCESO MÓVIL O LA RED MÓVIL.
Si el diagnóstico de la avería nos confirma que el problema se localiza en el acceso de la red móvil o
se necesita diagnosticar sobre la red de acceso móvil, se deberá encaminar la avería al Centro
Técnico Móvil mediante llamada al CAT Móvil: 1489 +700700700 y registrará Actuación externa a
CGC Móviles, indicando el número de eGRIM/REC. Este centro trabaja en el ámbito de TME y no
utiliza la misma herramienta de ticketing y gestión de averías (GDIA-Winest) que utilizan los Centros
de Excelencia de TdE, sino que utiliza la herramienta eGRIM.
Edición 1.8
Página 83 de 155
El CAT Móvil, a través de ATOS abrirá un eGRIM que generará una REC al CT Movilidad.
Una vez que la incidencia esté abierta por el Teléfono de la SIM, el Centro de Excelencia podrá
realizar seguimiento de la incidencia a través de la herramienta XLAN en la pestaña GRI:
PROBLEMAS DETECTADOS EN EL EDC O LA SIM
Si tras las pruebas realizadas con el cliente y con el CAT Móvil se determina que hay que desplazar un
técnico de I+M a la sede del cliente para realizar una actuación en el EDC, y debido a que el código de
Central para asignar la EECC lo toma de LOGOS-PT, es necesario que previamente se verifique:
Si el domicilio real no coincide con el de LOGOS-PT, GDIA consulta el código de Central A

asociado al domicilio y lo compara con el que está en LOGOS-PT. Si no coincide la Central A, da un
aviso informando de la central correcta para que el CEx la modifique en LOGOS-PT. En caso de fallo
de GDIA, se puede comprobar la Central A en MOS para el domicilio donde esté la incidencia.
No se puede abrir SIRIO mientras la central en LOGOS-PT no sea la correcta. Tener en cuenta
que la actualización de este dato en GDIA se hace cada 3 horas, y GDIA dará el aviso de Central A
incorrecta hasta que se actualice.
El número móvil por el que se abre el SIRIO debe coincidir con el que aparece en el campo
MSISDN de LOGOS-PT.
Edición 1.8
Página 84 de 155
Comprobar desde XLAN el último ticket GDIA abierto del cliente con SIRIO y si fue abierto por
MSISDN o Teléfono Ficticio, si fue así y dentro de las últimas 24 horas, SIRIO va a modificar los datos
del boletín, ignorando los enviados desde GDIA, entre ellos la dirección a la última avería registrada,
por eso si no corresponde con la dirección actual, se debe abrir Argonauta a SIRIO (SU) para que
borren los datos históricos de ese cliente, especificando el MSISDN o Teléfono Ficticio por el cual se
abrió esa avería, y se pueda abrir SIRIO con la dirección correcta.
La apertura de SIRIO desde GDIA automáticamente abre el SIRIO por el identificativo del
MSISDN. Después de abrir SIRIO verificar que los datos de la dirección no han sido modificados por
SIRIO (si se ha realizado el punto anterior no debería ocurrir).
En caso de apertura manual de SIRIO desde VANTIVE es importante que no haya ninguna
referencia al administrativo, se debe poner el MSISDN en el campo destinado al administrativo
(campo obligatorio), verificando que los datos en la pestaña “Datos de Cliente” (especialmente la
Provincia) es la correcta antes y después de abrir SIRIO.
A continuación, se detalla cómo realizar algunas de estas acciones:
Ver central correcta desde MOS (https://edomus.tesa/b3/).
Indicar domicilio
Edición 1.8
Página 85 de 155
Y pulsar
En la pestaña que sale hay un enlace a la información de la central
Al pasar el ratón nos dice la central asociada
Edición 1.8
Página 86 de 155
Ver Central en LOGOS-PT en Acceso/Datos del Acceso/Central A
Ver MSISDN en LOGOS-PT en Acceso/Red Móvil/MSISDN
Modificar Central en LOGOS-PT en Acceso/Datos del Acceso/Central A, en caso de no estar el

correcto.
Hasta que no esté el dato correcto en LOGOS-PT no se debe abrir SIRIO.
Desde GDIA, una vez cerrado el SIRIO, siempre se emitirá un pop-up recordando que en el caso de
haber sido necesario un cambio de SIM para la resolución de la incidencia, será necesario actualizar
el ICC de la SIM en LOGOS-PT.
Para más información sobre Accesos y respaldos móviles, remitirse al documento BTO-PYM-PYS-GUI-
35689 GUI_PROVISIÓN Y MTTO LÍNEAS MÓVILES VPN IP INFRAESTRUCTURA LNS.
6.3.2 INCIDENCIAS CON UN SEGUNDO OPERADOR
Apertura de incidencia en el Service Desk del 2º Operador.
Una vez registrada la incidencia en GDIA el CEX se pondrá en contacto con el 2º Operador a los
contactos proporcionados por el cliente para proceder a la apertura de incidencia con el nivel de
severidad correspondiente y en cualquier caso coherente con el registrado en GDIA.
Tras la apertura de la incidencia se actualizará GDIA y se confirmará al cliente que ya está el 2º

Operador gestionándola.
6.3.3 GESTIÓN DE ACCESOS A CDG/TIC
En las incidencias en las cuales es necesario desplazar a un técnico de I+M al CDG/TIC, además de
gestionar el correspondiente boletín de transferencia, se debe solicitar su acceso de la siguiente
manera:
Se realizan desde la pestaña “ACTUACIONES” de SAC VANTIVE mediante la apertura de una

“Actuación Interna” dirigida al inbox HASP N1 Admin servicios; debiendo indicarse en los
comentarios de dicha actuación los siguientes datos:
Edición 1.8
Página 87 de 155
atencionpersonalizadaggcc@telefonica.es
nn1das@telefonica.es
REVISIÓN DE ELEMENTOS DE COMUNICACIONES DEL CDG.
COMPROBACIÓN CABLEADO. SUSTITUCIÓN CABLEADO:
 Nombre del CDG, sala y bastidor.
 Hostname del EDC sobre el que actuar.
 Nombre del cliente final.
 Fabricante, modelo y número de serie del nuevo equipo a introducir.
 Nombre, apellidos, DNI, empresa, técnico o transportista.
 Día para el que se solicita el acceso y matrícula del vehículo del técnico.
REVISIÓN DE Leds. RESETEO DE EQUIPOS. CABLEADO RESPONSABILIDAD TSOL.CONEXIÓN

LATIGUILLO
DESCONEXIÓN LATIGUILLO:
 Nombre del CDG, sala y bastidor.
 Hostname del EDC sobre el que actuar.
 Nombre del cliente final.
 Descripción de la actuación solicitada (revisión de cableado si es responsabilidad de TSOL,

estado de luces, reseteo de equipo, etc.).
 Direcciones IP de los EDCs afectados.
 Teléfono de contacto 24 horas del centro o persona remitente de la actuación.
 Día para el que se solicita el acceso y matrícula del vehículo del técnico.
Para mayor conocimiento del proceso, se adjunta el documento que describe la operativa entre las
distintas áreas de Telefónica y los CDG/TIC que gestiona Telefónica Soluciones.
Edición 1.8
Página 88 de 155
Accesos a CDGs.doc
Edición 1.8
Página 89 de 155
6.4 A7 - INFORMACIÓN
El objetivo de esta actividad es el de mantener informado al cliente sobre la evolución de la

incidencia, y registrar en el sistema de ticketing los distintos contactos en el momento en el que se
han realizado a lo largo de la vida de la incidencia, documentando la información que se proporciona
al cliente. Es igualmente importante realizar los contactos a cliente para mantenerle debidamente
informado, como documentarlos correctamente en el sistema de ticketing para que quede
constancia de ello. En el ANEXO 2: PLAN DE COMUNICACION A CLIENTE se describe en detalle la
frecuencia, vía de comunicación y registro de las comunicaciones mínimas que deben realizarse en
cada incidencia.
Además de acortar los tiempos de actuación y la ausencia de problemas tras la reparación, uno de los
aspectos que más valoran nuestros clientes es la comunicación, que le puede ayudar a tomar
decisiones necesarias para su negocio. Los clientes que reciben algún tipo de información, bien sobre
la evolución, bien sobre la reparación de la avería manifiestan una satisfacción superior que los que
no la reciben.
Por ello, para cada incidencia, se debe identificar al interlocutor de cliente más adecuado según el
modelo de comunicación establecido con el Cliente, que será la persona a la que se mantendrá
informada durante la vida de la incidencia y debe tener la trazabilidad total de la evolución de la
misma. Los datos de contacto de dicho interlocutor deben quedar reflejados en la información global
del ticket de la herramienta de ticketing.
Si a lo largo del tratamiento de la incidencia fuera necesario contactar con algún contacto diferente
al interlocutor identificado (para realizar pruebas, coordinar visitas del técnico a la sede, etc.) será
necesario que el interlocutor de cliente esté informado de dichas acciones, ya sea incluyéndole en
copia de los correos electrónicos, enviándole un SMS, o mediante una llamada adicional al
interlocutor global del ticket una vez se hayan realizado las pruebas o se haya concertado la visita a la
sede.
Si durante la vida de la incidencia fuera necesario modificar el interlocutor de cliente deberán

actualizarse los datos en la información global del ticket y deberá justificarse dicho cambio de
interlocutor en los comentarios del ticket. En este caso deberemos asegurarnos de que el nuevo
interlocutor conozca el detalle de todo el tratamiento realizado hasta el momento del cambio.
En el registro de las comunicaciones siempre deberán figurar las personas a las que realmente
hayamos informado, aunque estas sean diferentes al interlocutor de cliente definido en la
información global del ticket.
Edición 1.8
Página 90 de 155
6.5 A8 - SEGUIMIENTO Y ESCALADO
En esta actividad se realiza el seguimiento extremo a extremo de las incidencias, peticiones,

consultas y reclamaciones asegurando que se cumplen los SLAs asociados al servicio, y escalando las
desviaciones detectadas para su corrección. Esto incluye la realización del seguimiento de todas las
incidencias transferidas, y el escalado de aquellas en las que sea necesario para asegurar el
cumplimiento de los SLAs establecidos, o donde así lo indique el procedimiento de escalado vigente.
En este punto se recogen todas las acciones a realizar para el correcto seguimiento y escalado de las
incidencias. En el sistema de ticketing se debe documentar toda la información que esté relacionada
con el ticket en un lenguaje legible para todas las áreas que participan en el proceso de gestión de
averías (Atención al Cliente, áreas operativas y técnicas), aportando una explicación y contexto lo
suficientemente claros para que cualquiera que lo lea lo entienda perfectamente. Solo se debe copiar
y pegar información de otras aplicaciones cuando se quiera complementar esta información
aportando pruebas adicionales, añadiendo el contexto suficiente que permita entender dichas
pruebas.
El seguimiento de las incidencias se realiza desde el propio sistema de ticketing, dependiendo del
servicio, además, si se procedió a hacer transferencia o despacho a otra área para su tratamiento,
también se debe hacer en el sistema de despacho donde se abrió la actuación, o con los medios
utilizados para realizar la transferencia.
Para facilitar el seguimiento de toda la actividad, en GDIA nos debemos apoyar en los gráficos y el
cuadro de mando que están disponibles en el menú “Tickets”. Los gráficos nos muestran las
incidencias en GDIA, las modificaciones no facturables en “Agenda/MNF”, y la provisión en
“Provisión”, según se explica en la guía operativa de GDIA.
Para las incidencias masivas, se utilizará la información que aporta XLAN y la web del CNCE, y
siguiendo las indicaciones del procedimiento para el tratamiento de las incidencias críticas y masivas
de la BTO.
Las incomunicaciones totales deben registrarse en el sistema de ticketing, tantas veces como
ocurran, y finalizarse cada vez que se recupere el servicio.
En los casos en los que los franqueos de los boletines SIRIOS vengan sin información, NO se deberá
rechazar el franqueo, sino que se deberá contactar con los Centros de Servicios para recopilar la
información necesaria al respecto de ese franqueo, evitando así pérdidas de tiempo.
Para cualquier incidencia generalizada y relacionada con los sistemas de ticketing o de transferencia,
deberá generarse una incidencia en Argonauta, o asociarse a la masiva relacionada.
6.5.1 ASEGURAMIENTO DEL PROCESO DE RESOLUCIÓN DE INCIDENCIAS
EL CGE/CEX es responsable extremo a extremo de la resolución del ticket, lo que incluye el

seguimiento y escalado del mismo.
Edición 1.8
Página 91 de 155
Agentes involucrados en cada Avería:
CGE/CEX se trata de la Unidad que ve el cliente de forma total y en consecuencia conoce de

primera mano lo que ocurre del lado del cliente (imposibilidad de acceso, prioridades, horarios…
etc.). Su atribución y responsabilidad más importante es que, para una avería, es el responsable final
de su resolución y en consecuencia es responsable de coordinar a todos los posibles Agentes de
Resolución, así como de propiciar los escalados informativos oportunos.
Unidades Agentes de Resolución, puede ser una o varias unidades de TE que en un momento
de vida de la avería tienen bajo su responsabilidad la actuación para concluir la resolución de esta.
Como norma el CGE/CEX tiene la obligación de documentar TODAS las incidencias que tengan un
tiempo superior a 12 horas en observaciones de GDIA marcando el envío a SIRIO. La documentación
del ticket deberá mantenerse lo más actualizada posible durante la duración de la avería.
El CGE/CEX se podrá poner en contacto con la Unidad Agentes de Resolución que tenga en ese
momento la avería para pedir agilización o corrección del proceso.
Cuando la comunicación se realice por correo electrónico, se incluirá en copia del correo a
TE_CONTROL_DE_ESCALADOS controldeescalados@telefonica.com y el asunto se compondrá de
una cadena de texto, encadenando diferentes campos de información relativos al escalado,
separados por el carácter “/”, con el siguiente orden y contenido:
Provisión Tipo de Nombre Localidad - Serie del ticket principal
Campo CIF Cliente Servicio Afectación Otras referencias
/ Avería Petición Cliente Provincia de la avería escalada
LORCET:[Código del
ticket]
TELESAP:[Código del
SAC:[Código del ticket]
ticket]
SIRIO:[Código del ticket]
INCOMUNICACIO CAE:[Código del ticket]
ESC [Localidad de la SAM:[Código del ticket]
Valores PROV [CIF de [Nombre [Servicio N GRI:[Código del ticket]
PRI sede]-[Provincia de ITSM:[Código del ticket]
Posibles AVE Cliente] de Cliente] afectado] DEGRADACION SIRIO:[Código del ticket]
INF la sede] E-GRIM:[Código del
{OTROS} GAOM:[Código del
ticket]
ticket]
{OTROS}
AGENDA:[Código del
ticket]
{OTROS}
Carácter Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Obligatorio Opcional
Según (*) Se concatenarán tantas
tipificación referencias como sean
Observaciones
en necesarias, separadas por
AGENDA "/"
Donde:
o PROV: Provisión
o AVE: Avería
o ESC: Escalado. Casos muy particulares (ver tipificación escalado)
o PRI: Priorizaciones. Aquí se engloba la mayoría de las peticiones actuales (ver tipificación escalado)
o INF: Petición de información (ver tipificación escalado)
o Serie del ticket principal: Para averías de Datos y Voz será el código de avería de GDIA.
Ejemplo Asunto:
AVE / PRI / A82018474 / Telefónica de España / Leganés – Madrid / MACROLAN /
INCOMUNICACION / SAC:123456 / SIRIO:XXXXXXX / GRI:XXXXXXXXXXX / GAOM:XXXXX
Edición 1.8
Página 92 de 155
Tipificación de escalados (tipo de petición)
Escalado: Exigencia diferencial y puntual que viene acompañada de una causa justificada
sobre un documento ejecutivo. Priorización sobre el resto de las averías.
TIPOLOGIAS DE ESCALADOS
Escalado VIP: autorizado por director aportando datos esenciales. Si no hay avería hay que gestionar
su apertura.
Impacto Imagen de Marca: impacto en la imagen de Telefónica que debe estar validada por el Director
de la UUNN con el motivo.
Impacto Negocio: impacto severo en el negocio del cliente que debe estar validado por el Gerente de
la UUNN con el motivo.
Cambios de alcance en el impacto respecto al inicial
Incumplimientos de SLA/SLO en circuitos marcados como críticos
Coordinación entre distintas áreas cuando en el proceso no se soluciona por sí mismo.
Priorizaciones: Necesidad de atención más ágil dentro de los procedimientos de cada una de
las distintas áreas y servicios.
TIPOLOGIAS DE PRIORIZACIONES
Incumplimientos: la avería no se ha resuelto o el SLA/SLO se ha incumplido
Operativas de Atención: gestiones realizadas por operativas de las distintas unidades sin tener en
cuenta el estado de la avería
Petición de información: Necesidad de obtener/aportar información sobre una avería.

TIPOLOGIAS DE INFORMACIÓN
Aportación: aportar información a las áreas resolutoras
Solicitud: gestiones realizadas por operativas de las distintas unidades sin tener en cuenta el estado de
la avería
Para la unidad de I+M se ha establecido un modelo de escalado específico regido principalmente por
el cumplimiento de una serie de condiciones previas antes de producirse dicho escalado, así como el
canal y la manera de escalar en cada momento.
Los criterios establecidos para iniciar el proceso de escalado hacia I+M son:
Cliente disponible (contacto y teléfono)
Casuística:
> SLA de incomunicación de Sede
Incidencias con > 48h sin cita y reclamada por cliente
Edición 1.8
Página 93 de 155
El canal de comunicación establecido por defecto será el correo para el escalado operativo siguiendo
los criterios establecidos (escalados.im@telefonica.com) atendido de Lunes a Viernes (no festivos) de
8:00 a 18:30.
Fuera de ese horario se escalará directamente a la EECC de I+M según información residente en el
propio ticket de GDIA o a través de búsqueda en
https://gen-gdia-auxi-02.ctic/WebEscalados/Listado.php
Se han definido unos SLOs de respuesta por parte de I+M a los escalados del buzón siguiendo el
siguiente protocolo:
Envío de 1º escalado a escalados.im@telefonica.com
SLO Respuesta
< 2h desde 1º correo de escalado
Envío de 2º escalado a escalados.im@telefonica.com
SLO Respuesta
Edición 1.8
Página 94 de 155
< 1h desde 2º correo de escalado (compromiso incumplido o falta de respuesta al

primero)
+ 1h desde 2º escalado, llamada a estructura
Y se ejemplifica en el siguiente gráfico:
El escalado jerárquico a la estructura de TdE (a partir de la 3ª hora desde el envío del escalado) se
efectuará a través de teléfono usando para ello el mapa de OOLL dónde escogiendo la provincia,
servicio, tipo y pinchando en la Columna de Cliente / Router se obtiene la información de la
estructura de I+M responsable de ese servicio en esa provincia.
https://cnce.es.telefonica/web/mapa_responsables/MAPA_Inicio.php.
Edición 1.8
Página 95 de 155
El formato de envío de los correos de escalado seguirá las directrices generales definidas en este
mismo apartado.
En el caso de que no encontremos el contacto adecuado, recurriremos a la persona o área más

indicada dentro de la organización según el proceso en el que nos encontremos de la incidencia. Para
ello podemos consultar el directorio de Operaciones y Red que se puede encontrar en la intranet de
Telefónica (http://edomus.tesa):
http://canal.infraestructuras/canaltos/RRHHOyR/estructuraor.asp?uo=034534&nivel=TODOS
Para consultas y peticiones (principalmente cuando no exista información en las herramientas)

referentes a actuaciones en OOLL de I+M fuera del ámbito de un escalado contactar con los
siguientes buzones organizados según tipo de servicio:
TE_I+M EC MMTO Macrolan <imec.mmtomacrolan@telefonica.com>
TE_VPN_MANTENIMIENTO <VPN.mantenimiento@telefonica.com>
TE_ESCALADOS_ IM <escalados.im@telefonica.com>
La información de quién atiende la incidencia, por servicio y tramo en el que se encuentra la misma
se puede consultar la web:
https://cnce.es.telefonica/web/mapa_responsables/MAPA_Inicio.php
https://cnce.es.telefonica/web/guia-grafica/guia_grafica.php
6.5.2 INCIDENCIAS RECIBIDAS
Estas incidencias deben asignarse para iniciar cuanto antes su tratamiento, debido a que durante la
primera hora se deben realizar las primeras comprobaciones, establecer un primer diagnóstico,
documentar, y realizar el primer contacto a cliente. Se debe procurar que las incidencias estén el
menor tiempo posible es este estado, para evitar que haya incidencias sin tratar.
6.5.3 INCIDENCIAS SIN CONTACTO PRIMER DIAGNÓSTICO
Se trata de las incidencias que, estando ya asignadas, aún no tienen el contacto de primer
diagnóstico realizado y documentado según el plan de comunicación a cliente, que estipula que se
debe realizar dentro de la primera hora. Nos debemos asegurar de que este contacto se realice y
documente dentro del plazo establecido.
6.5.4 INCIDENCIAS SIN SIRIO
En las incidencias sin boletín SIRIO, es decir que no han sido transferidas del Nivel 1 del CEx/CGE al
Nivel 2 del CdS, nos debemos asegurar de que se están tratando y que tenemos el diagnóstico
correcto, para confirmar su resolución por parte del CEx/CGE sin necesidad de ser transferida a otra
Edición 1.8
Página 96 de 155
área, de lo contrario se deben analizar los motivos por los cuales no se ha realizado la transferencia, y
seguidamente proceder cuanto antes con ello.
Debemos tener en cuenta que en algunos servicios esta transferencia se realiza en otros sistemas de
despacho o por otros medios, que aplican igualmente, pero que GDIA no las muestra.
Estas incidencias deben ser revisadas y documentadas antes de contactar con el cliente, siguiendo el
modelo de comunicación.
6.5.5 INCIDENCIAS REPETIDAS
En el caso de las incidencias repetidas, se debe comprobar y analizar el histórico de incidencias, y

aplicar el procedimiento de gestión de problemas de la actividad “A11-Gestión de Problemas”, con el
objetivo de identificar patrones y la causa origen del problema. En este tipo de incidencias se debe
hacer un seguimiento especial diario, revisar el estado, actuar, e informar a cliente.
6.5.6 INCIDENCIAS DEVUELTAS
Son aquellas incidencias en las cuales el cliente ha rechazado el cierre de estas por considerar que el
problema no está resuelto. En este caso se deben analizar los motivos que argumenta el cliente para
el rechazo. Seguidamente, debemos revisar las comprobaciones y actuaciones realizadas y la
resolución aportada por el CEx/CGE. Con toda esta información, debemos repetir las comprobaciones
que se estimen necesarias para confirmar si procede el rechazo del cliente y reabrir la incidencia, o
por el contrario obtener la pruebas que argumentaremos al cliente de la improcedencia del rechazo.
Siempre necesitamos la conformidad de cliente para proceder con el cierre de la incidencia.
6.5.7 INCIDENCIAS DE MAS DE 24 HORAS
En las incidencias de más de 24 horas, se debe hacer un seguimiento diario, documentando todas las
actuaciones y contactos, marcando siempre el envío a SIRIO, para que la información quede
correctamente documentada en el ticket. Además, nos debemos asegurar de que la incidencia está
debidamente tratada y encaminada, intentado agilizar al máximo su resolución.
6.5.8 INCIDENCIAS DE MÁS DE 48 HORAS
Para el seguimiento y escalado de todas las incidencias que superen las 48 horas, será necesario que
diariamente se incluya en el campo “Observaciones” de GDIA, y se marque el envío a SIRIO, la
información que se detalla a continuación. El informe se extraerá a las 11 de la mañana, por lo que es
importante que las incidencias estén actualizadas antes de dicha hora.
La presente operativa se debe realizar por los gestores de servicio técnico en aquellos servicios con
las modalidades de gestión CGE, CEX PREMIUM+, CEX PREMIUM y CEX AVANZADOS. En aquellos
servicios correspondientes con la modalidad de gestión CEX (antiguo CG ESTANDAR) se deberá
realizar por los interlocutores designados por el proveedor externo.
Edición 1.8
Página 97 de 155
Es muy importante que se respete el siguiente formato:
[Identificador único de Incidencia; Unidad responsable de la desviación; Causa desviación operativa;

Observaciones; T Desviación]
donde:
Identificador único de Incidencia: Serie GDIA
Unidad responsable de la desviación: Para ello se incluirá la abreviatura de cada unidad

responsable (marcada en negrita a continuación):
GdSt: Gestor de Servicio técnico

OpCEx: Operación CEX
CdS: Centro de Servicio
I+M: Operación Local
O+M:
CGC: Centro Grandes Clientes
SopTSO: Soporte TSO
Cliente: Cliente
Comercial: Comercial
Otros: Cualquier otro grupo no contemplado en los anteriores.
Causa desviación operativa: Incluir para cada caso la abreviatura que se marca en negrita:
o SD: Sin desviación, la incidencia está más de 48 h, pero gestionada correctamente

o EH: Error humano, un operador con capacidad y competencia ha cometido un error
o Proc: Indefinición del proceso, un operador con capacidad y competencia ha
retrasado la resolución porque el procedimiento no contemplaba el caso o admitía
interpretación
o Capac: Carencia de capacitación, un operador ha causado retraso por falta de
conocimiento (técnico o del proceso)
o Praxis: Mala praxis, un operador con capacidad y competencia ha actuado con
negligencia o dejadez
o Stock: Rotura de stock, la resolución está pendiente por falta de material
o Encolada: Carencia de capacidad/recursos, no se puede atender la incidencia por
falta de recursos o está encolada, pendiente de resolución y fuera de SLO/SLA
o Masiva: Incidencia afectada por una incidencia masiva
o PRL: Incidencia pendiente de documentación PRL para que los técnicos de campo
puedan acceder a la sede de cliente.
o Cita: Solo se debe de utilizar cuando el cliente no pueda atender al técnico de
telefónica y se acuerde una cita para realizar la intervención.
o Otros: Otra desviación no contemplada en las anteriores
Observaciones: Texto libre. Corto y con enfoque constructivo.
Edición 1.8
Página 98 de 155
T Desviación: Tiempo de contribución (en horas) del área responsable de la desviación. En

aquellas incidencias donde la desviación sea imputable a una única causa este campo es
recomendable pero opcional. Será obligatorio únicamente en aquello casos donde haya varias causas
que contribuyan a la desviación.
Es imprescindible que la información se incluya entre corchetes [] y separada por puntos y coma “;“
A continuación, se muestran varios ejemplos:
[63XXX; Cliente ; Cita ; Visita concertada para el 18/11/19;21]

[62XXXX; I+M ; Stock ; Breve descripción;25]
[654XXX ; Otros ; Otros ; Incidencia escalada a Nokia;12]
[654XXX ; Comercial ; Otros ; Comercial. Pdte de resolución de Caronte;200]
Si hay más de un área que contribuye a dicha desviación (algo frecuente), se añadirá una
línea por cada una (OpCex, I+M, O+M, etc), separadas por corchetes cada una. Por ejemplo:
[63XXX ; I+M ; PRL ; Pendiente de documentación PRL para que el técnico de campo pueda
acceder a la sede del cliente ;72] [63XXX ; Cliente ; Cita ; Visita concertada para el 18/11/19 ;85]
[63XXX ; Comercial ; Otros ; Pdte. de resolución de Caronte ; 650]
IMPORTANTE:
Respetar el orden indicado
Respetar los separadores utilizados (;)
Utilizar solo los responsables y causas indicadas, si es necesario alguno más indicarlo en el
campo de observaciones para su estudio
Si se estima necesario incluir información adicional indicarlo en el campo observaciones
Es necesario incluir la información para todas las incidencias sin excepción, esto incluye
clientes estándar/avanzados/premium, incidencias en estado resuelta, incidencias locales,
incidencias en fase de servicio provisión, etc.
Si hay más de un área que contribuye a dicha desviación, se añadirá un comentario por cada
una (OpCex, I+M, O+M, etc), separadas por corchetes cada una
Diferenciar entre el estado actual de la incidencia y la razón de la desviación, el comentario
tiene que reflejar la razón de la desviación
Para cualquier duda o problema que pueda surgir, se deberá enviar un correo a
TSO_PROCESOS
Edición 1.8
Página 99 de 155
6.6 A9 - RESOLUCIÓN
En esta actividad se llevan a cabo las acciones necesarias cuando se ha solucionado el problema que
afectaba al circuito, equipo o servicio.
Una vez determinado que se ha solucionado el problema en los elementos afectados, se restablece la
operatividad completa del servicio, y se identifica claramente la causa, localización y responsable, se
registra la solución en el ticket. En GDIA esta acción cambiará el estado del ticket a “Resuelta.
Seguidamente se debe realizar y registrar en el ticket de GDIA el contacto de observación/resolución
a cliente según lo definido en el ANEXO 2: PLAN DE COMUNICACION A CLIENTE.
Si durante el periodo que el ticket se encuentra en estado “En observación-Verificación” o

“Resuelta”, el cliente o el CEx detecta que la incidencia se ha reproducido, se pasará en dicho
momento al estado “En solución” comenzando de nuevo todo el proceso de análisis y nueva
solución.
En el caso de un ticket que se encuentran en estado “En Observación-Verificación” o “Resuelta”, y se

haya confirmado la resolución del problema con la conformidad del cliente, se pasará al estado
“Cerrada” descrito en las tareas de la actividad “A10-Confirmación de cierre”.
En ningún caso un ticket en estado “En Observación-Verificación” podrá pasar al estado “Resuelta”,
ya que si el problema se ha solucionado se debe pasar directamente a “Cerrada”, o en el caso de que
el problema se haya reproducido se debe pasar al estado “En solución”.
Es obligatorio documentar cómo se ha resuelto la incidencia, incluyendo las pruebas que avalan su
correcto funcionamiento.
En CGE NO 7x 24, cuando se produzca el franqueo de un boletín SIRIO fuera del horario del centro, el
CEx encargado de realizar el desborde identificará un aviso de “Franqueo de Sirio” y deberá
comprobar que se ha solucionado el problema, y si es así, pasar la incidencia a estado “Resuelta”.
En las incidencias en las cuales ha sido necesario transferir vía boletín Sirio, cuando se reciba el
franqueo del área resolutora, se dispone de 2 horas para comprobar que el problema esté resuelto y
confirmar el franqueo, o solo en el caso en el que el problema no se haya solucionado o persista se
puede rechazar el franqueo.
En los casos en los que sea necesario confirmar con el cliente la resolución y no se consiga contactar
con él en las 2 horas siguientes al franqueo, dado que el Sirio se habrá franqueado de forma
automática, si el problema persiste o se ha reproducido se debe proceder con la apertura de un
nuevo boletín Sirio.
6.6.1 TABLAS DE RESOLUCIÓN/CIERRE POR SERVICIO
Los parámetros “responsable”, “localización” y “causa” se deben corresponder con los establecidos
en el árbol de resolución de las siguientes tablas de cierres por servicios, que contienen las únicas
posibilidades válidas para estos campos:
Edición 1.8
Página 100 de 155

DATOS (MACROLAN, VPN IP, DATAINTERNET, FLEXWAN):
RESPONSABLE LOCALIZACIÓN CAUSA DETALLE
Fallo eléctrico/falta fluido domicilio El cliente tiene un problema de electricidad y el

cliente router se apaga.
Problemas en la LAN del cliente El problema está en la LAN del cliente.

Domicilio/
Infraestructura/Servicios
de cliente Para incidencias locales en las que el cliente ha
demorado la atención en un tiempo superior a 48
Cliente demora la atención de la
horas laborables, y que tras este período la
incidencia
incidencia no se ha resuelto o el diagnóstico
inicial es erróneo.
El cliente manipula indebidamente el router y

Mala operación
provoca avería.
Configuración desde el CEx/CGE a petición de

Configuración desde el centro de
cliente. Modificaciones no facturables solicitadas
gestión
por cliente.
Avería software en equipos propiedad de cliente

Problema software para los que no tenga contratado el
EDC-Router mantenimiento.
CLIENTE Avería hardware de un equipo propiedad de

Problema hardware cliente para el que no tenga contratado el
mantenimiento y el cliente tenga que reponerlo.
El cliente declina que el CEx realice pruebas de

Pruebas de respaldo
backup en una sede o en un conjunto de sedes.
Vandalismo/robos Se auto explica
Vandalismo/robos Se auto explica
El cliente manipula la línea de acceso en sus

Mala operación
Línea de acceso dependencias provocando avería.
El cliente genera tráfico en exceso que satura la

Superación del caudal
línea provocando cortes y lentitud.
Por ejemplo, avería en una línea de otro operador

Mala operación
que por error nos las abren a nosotros.
Proveedor servicios cliente
Fallo eléctrico/falta fluido domicilio El cliente se queda sin suministro eléctrico por
cliente culpa del suministrador.
Telefónica EDC-Router Problema software Fallo de software, actualizaciones
Problema hardware Fallo de hardware
Configuración desde el centro de Incidencias provocadas por fallo de configuración.

gestión
Edición 1.8
Página 101 de 155

Configuraciones realizadas por Trabajos

Programados.
Configuraciones realizadas tras una revisión de

los equipos solicitada por el CdS.
Configuración desde el CEx/CGE a petición del

CdS. Modificaciones no facturables solicitadas
por CdS.
Error responsabilidad de Telefónica, como pedir

Mala operación una baja, dejar mal conectado el router en una
migración, etc.
Para registrar que el centro ha realizado pruebas

Pruebas Respaldo
de respaldo.
Diagnóstico apuntando a esta localización, pero

Desaparecida
desaparece la avería sin causa localizada.
Por un problema de configuración

Superación del caudal responsabilidad de Telefónica se provoca una
superación del caudal.
Incidencia que cause pérdida de gestión y/o

FALLO EN SERVICIO DE SUPERVISIÓN monitorización, pero no afecte al Servicio.
(Incluye problemas con vista portal TEDI).
Problema software Fallo de software o configuración
Algún error como pedir una baja, un cambio de

Mala operación
puerto que no hagamos bien, etc
Diagnóstico apuntando a esta localización, pero

Desaparecida
Línea de acceso desaparece la avería sin causa localizada.

AVERÍA MASIVA Informar la incidencia masiva
TRABAJO PROGRAMADO Auto explicativo. Informar BTP.
Red IP Problema software Fallo de software o configuración
Mala operación en red IP que provoca avería,

Mala operación
excluyendo BTPs e incidencias masivas.
Desaparecida Diagnóstico apuntando a esta localización, pero

desaparece la avería sin causa localizada.
Edición 1.8
Página 102 de 155


AVERÍA MASIVA Informar la incidencia masiva.
TRABAJO PROGRAMADO Auto explicativo. Informar BTP.
Se diagnostica y resuelve la avería indicando que

no está en un servicio gestionado por GDIA,
Cloud Otro sistema de ticket
apuntando al servicio donde realmente estaría el
problema.
Se diagnostica y resuelve la avería indicando que

no está en un servicio gestionado por GDIA,
Entorno Puesto de Trabajo Otro sistema de ticket
apuntando al servicio donde realmente estaría el
problema.
Fallo IPSEC Problema en el cifrado IPSEC
Encolamiento u otro tipo de fallo en UBR Legacy o

Fallo UBR Gateway provocando descartes en el tráfico de
cliente
Fallo VSD Fallo en los servidores VSD o sus bases de datos

Plataforma (Sólo para
FlexWAN) Fallo en los servidores VSC o de su tráfico
Fallo VSC
Openflow con los NSGs
Fallo de acceso al portal o de cualquiera de sus

Fallo Portal
funcionalidades
Fallo de la plataforma de informes de dejándolos

Fallo Informes
indisponibles o con datos erróneos.
SILAN Y FLEXSITE:
RESPONSABL
LOCALIZACIÓN CAUSA DETALLE
E
Fallo eléctrico/falta fluido domicilio El cliente tiene un problema de electricidad y

cliente el equipo se apaga.
El cliente tiene un problema en su LAN.

Problemas en la LAN del cliente Válido para escenario de convivencia SILAN
Domicilio/Infraestructura/Servicios con LAN de cliente
Cliente de cliente
Para incidencias locales en las que el cliente
ha demorado la atención en un tiempo
Cliente demora la atención de la
superior a 48 horas laborables, y que tras
incidencia
este período la incidencia no se ha resuelto o
el diagnóstico inicial es erróneo.
EDC-Punto de acceso Mala operación Manipulación HW o cableado por parte del
Edición 1.8
Página 103 de 155

cliente.
Cualquier problema de cliente que no sea de

Desaparecida
los anteriores

cliente. Modificaciones no facturables
gestión
solicitadas por cliente.
Vandalismo/robo Se auto explica
Manipulación HW o cableado por parte del

Mala operación
cliente.

cliente. Modificaciones no facturables
gestión
EDC-Switch solicitadas por cliente.

Desaparecida
los anteriores
Vandalismo/robo Se auto explica
Firewall caído o no operativo FW propiedad de cliente o de un tercero

Firewall
Reglas de Firewall incorrectas FW propiedad de cliente o de un tercero
Mala Configuración Error parametrización cliente.
GCU (Gestión Cloud de Usuarios)

Desaparecida
los anteriores
Fallo eléctrico/falta fluido domicilio El cliente se queda sin suministro eléctrico

Proveedor servicios cliente
cliente por culpa del suministrador.
Mala Configuración Error configuración CdS SILAN / CEX / CGE
Mala operación Manipulación HW o cableado por OOLL.
Avería HW / Fuente de Alimentación /

Problema hardware
Interfaz…
EDC-Punto de acceso Diagnóstico apuntando a esta localización,

Desaparecida pero desaparece la avería sin causa
localizada.
Telefónica
Firmware no homologado / Software

Problema software
corrupto
Configuración desde el Centro de

Mantenimiento Correctivo
Gestión
Mala Configuración Error configuración CdS SILAN / CEX / CGE

EDC-Switch
Mala operación Manipulación HW o cableado por OOLL.
Edición 1.8
Página 104 de 155

Diagnóstico apuntando a esta localización,

Desaparecida pero desaparece la avería sin causa
localizada.
Avería HW / Fuente de Alimentación /

Problema hardware
Interfaz…
Firmware no homologado / Software

Problema software
corrupto
Firewall caído o no operativo FW gestionado por TdE

Firewall
Reglas de Firewall incorrectas FW gestionado por TdE
GCU (Gestión Cloud de Usuarios) Mala Configuración Error configuración CdS SILAN
RPV INTERNACIONAL (MODALIDAD PRESTADORA):
RESPONSABLE TIWS LOCALIZACIÓN TIWS CAUSA TIWS DETALLE
Cliente Customer Fallo eléctrico/falta Power Se auto explica. El cliente tiene un

fluido domicilio supply problema de electricidad y el router
cliente failure se apaga.
Customer
Problemas en la LAN device / Se auto explica. El problema está en
Domicilio/ Customer del cliente Network la LAN del cliente.
Infraestructura/ Premise failure
Servicios de cliente Equipment
Para incidencias locales en las que el
cliente ha demorado la atención en
Cliente demora la
un tiempo superior a 48 horas
atención de la
laborables, y que tras este período la
incidencia
incidencia no se ha resuelto o el
diagnóstico inicial es erróneo.
Human El cliente manipula indebidamente el

Mala operación
error router y provoca avería.
Avería hardware de un router

Device
propiedad de cliente para el que no
Customer Problema hardware router
tenga contratado el mantenimiento
EDC- Router Premise damaged
y el cliente tenga que reponerlo.
Equipment
Software Router propiedad de cliente y tiene

Problema software
error un software con problemas.
Vandalismo/robos Others Auto explicativo
Línea de acceso Others El cliente manipula indebidamente el

Mala operación Others
router y provoca avería.
Vandalismo/robos Others Auto explicativo
Edición 1.8
Página 105 de 155

Superación del
Others Auto explicativo
caudal
Fallo eléctrico/falta Power El cliente se queda sin suministro

fluido domicilio supply eléctrico por culpa del
Customer cliente failure suministrador.
Proveedor servicios
Premise
cliente
Equipment Por ejemplo, avería en una línea de
Human
Mala operación otro operador que por error nos las
error
abren a nosotros.
Avería desaparece sin saber la causa

Disappear pero el diagnóstico inicial apuntaba
Desaparecida
ed al router (sin configuración realizada
por TIWS previamente).
Human Error humano sobre router que

Customer Mala operación
error provoca avería.
EDC- Router Premise
Equipment
Device
Problema hardware router Fallo de hardware
damaged
Software Fallo de software, ajeno a acciones

Problema software
error por parte de TIWS
Auto explicativo. Indicar código de

AVERÍA MASIVA Others
TdE para la masiva
Diagnóstico apuntando a esta

Disappear
Desaparecida localización, pero desaparece la
ed
avería.
Telefónica
Telefónica Human Algún error puntual por parte de
(CPE o tramo Mala operación
OB error TDE en red de Core
nacional
Device Fallo de hardware en equipos

Local Problema hardware
damaged gestionados por TdE en red de CORE
Red IP Backbone
Network
Fallo de software o configuración en
Software
Problema software equipos gestionados por TdE en red
error
de CORE
Network
Superación del Saturación en nodos PE, equipos de
congestio
caudal tránsito
n
Notified
TRABAJO Auto explicativo. Indicar código de
scheduled
PROGRAMADO BTP
work

AVERÍA MASIVA Others
TdE para la masiva
Línea de acceso Local Loop

Disappear
ed
avería.
Edición 1.8
Página 106 de 155

Human Algún error puntual por parte de

Mala operación
error TDE

Problema hardware
damaged gestionados por TdE
Software Fallo de software o configuración en

Problema software
error equipos gestionados por TdE
Transit
Superación del
network Saturación en nodos DSLAM / OLT…
caudal congestion
Notified
TRABAJO Auto explicativo. Indicar código de
scheduled
PROGRAMADO BTP
work
TIWS (tramo Telefónica Configuración desde Configura Fallo de configuración en EDC por
internacional) TIWS el centro de gestión tion error parte del CT TIWS.

Disappear
ed
avería.
Incidencia que cause pérdida de

FALLO EN SERVICIO Unconven
gestión y/o monitorización pero no
DE SUPERVISIÓN tional
afecte al Servicio.
Customer
EDC- Router Premise Error humano o de automatismo por
Equipment Human
Mala operación parte del CT TIWS que provoque
error
avería. Baja indebida.
Actualización de software llevada a

Software
Problema software cabo por parte del CT de TIWS que
Error
derive en incomunicación
Transit
Superación del network Por un problema de configuración se
caudal congestio provoca una superación del caudal.
n
Red Internacional International Diagnóstico apuntando a esta

Backbone Disappear localización, tramo internacional,
Desaparecida
Network ed pero que no se ubique el origen de
esta.
Error humano o de automatismo por

Human parte de cualquier equipo de TIWS
Mala operación
error que derive en incomunicación del
acceso (generalmente masiva).
Device Fallo de hardware en equipos de red

Problema hardware
damaged internacional.
Problema software Software Fallo de software o configuración en

error equipos de red nacional.
Edición 1.8
Página 107 de 155

Transit
Superación del network
Saturación en POI´s contra nacional
caudal congestio
n
Notified
TRABAJO Auto explicativo. Indicar código
scheduled
PROGRAMADO trabajo programado
work

AVERÍA MASIVA other
incidencia masiva
RPV INTERNACIONAL (MODALIDAD DISTRIBUIDORA):
RESPONSABLE TIWS LOCALIZACIÓN TIWS CAUSA TIWS DETALLE
Cliente Customer Se auto explica. El cliente

Power
Fallo eléctrico/falta tiene un problema de
Supply
fluido domicilio cliente electricidad y el router se
Failure
apaga.
Customer
Problemas en la LAN device / Se auto explica. El problema
del cliente Network está en la LAN del cliente.
Domicilio/ Customer
failure
Infraestructura/ Premise
Servicios de cliente Equipment
Para incidencias locales en las
que el cliente ha demorado la
atención en un tiempo
Cliente demora la
superior a 48 horas
atención de la
laborables, y que tras este
incidencia
período la incidencia no se ha
resuelto o el diagnóstico
inicial es erróneo.
EDC- Router / Frad / Customer El cliente manipula

TimeStep / Centralita Premise Mala operación Human error indebidamente el router y
Equipment provoca avería.
Avería hardware de un router

propiedad de cliente para el
Router
Problema hardware que no tenga contratado el
damaged
mantenimiento y el cliente
tenga que reponerlo.
Router propiedad de cliente y

Software
Problema software tiene un software con
error
problemas.
Configuración desde el
Others Para registrar las MNFs.
centro de gestión
Superación del caudal Transit Auto explicativo.

network
Edición 1.8
Página 108 de 155

congestion
Vandalismo/robos Accident Auto explicativo
El cliente manipula la línea de

Línea de acceso Others Mala operación Others acceso en sus dependencias
provocando avería.
Cut off El cliente se queda sin

Fallo eléctrico/falta
caused by suministro eléctrico por culpa
fluido domicilio cliente
contracts del suministrador.
Customer
Proveedor servicios
Premise
cliente Por ejemplo, avería en una
Equipment
línea de otro operador que
Mala operación Human error
por error nos las abren a
nosotros.
TIWS Provider Avería desaparece sin saber la

(tramo causa pero el diagnóstico
internacional) Desaparecida Disappeared inicial apuntaba al router (sin
configuración realizada por
Customer TdE previamente).
EDC- Router / Frad /
Premise
TimeStep / Centralita
Equipment Router
damaged
Software Fallo de software, ajeno a

Problema software
error acciones por parte de TdE.
Auto explicativo. Indicar

AVERÍA MASIVA others
código de TIWS para la masiva

Desaparecida Disappeared localización, pero desaparece
la avería.
Error humano o de
automatismo por parte de
cualquier equipo de TIWS que
derive en incomunicación.
International Fallo de hardware en

Red Internacional Device
Backbone Problema hardware elementos de red gestionados
damaged
por TIWS.
Fallo de software o
Software
Problema software configuración en elementos
error
de red gestionados por TIWS.
Network Saturación en nodos de red de

congestion TIWS.
Notified Auto explicativo. Indicar

TRABAJO
scheduled código de TIWS para el
PROGRAMADO
work trabajo
Línea de acceso Local Loop AVERÍA MASIVA others Auto explicativo. Indicar
Edición 1.8
Página 109 de 155

código de TIWS para la masiva

la avería.
Algún error puntual por parte

del proveedor local
Fallo de hardware en equipos

Device
Problema hardware gestionados por proveedor
damaged
local
Fallo de software o
Software configuración en equipos
Problema software
error gestionados por proveedor
local
Saturación en nodos de red

Network
Superación del caudal gestionados por proveedor
congestion
local
Notified Auto explicativo. Indicar

TRABAJO
scheduled código de TIWS/Proveedor
PROGRAMADO
work local para el trabajo.
Telefónica Customer EDC- Router / Frad / Customer Configuración desde el Configuratio Fallo de configuración en EDC
(CPE o tramo TimeStep / Centralita Premise centro de gestión n error por parte del CEx.
nacional) Equipment
la avería.
Incidencia que cause pérdida

FALLO EN SERVICIO DE Unconventio
de gestión y/o monitorización
SUPERVISIÓN nal
pero no afecte al Servicio.
Error humano o de
automatismo por parte del
CEx que provoque avería. Baja
indebida.
Pruebas Respaldo Others Failover
Actualización de software
Router
Problema software llevada a cabo por parte del
damaged
Cex.
Notified
TRABAJO Pruebas de QoS y otros
scheduled
PROGRAMADO trabajos programados
work
Superación del caudal Transit Por un problema de

network configuración nuestro
congestion provocamos una superación
del caudal.
Edición 1.8
Página 110 de 155


localización, tramo nacional,
Desaparecida Disappeared
pero que no se ubique el
origen de esta.
Error humano o de
automatismo por parte de
cualquier equipo de
Mala operación Human error Telefónica de España que
derive en incomunicación del
acceso (generalmente
masiva).

Local Problema hardware
Red IP damaged de red nacional.
Backbone
Fallo de software o
Software
Problema software configuración en equipos de
error
red nacional.
Network Saturación en POI´s contra

congestion Internacional
Notified
TRABAJO
scheduled Auto explicativo. Indicar BTP
PROGRAMADO
work
Auto explicativo. Indicar

AVERÍA MASIVA others
código de incidencia masiva
VOZ (IBERCOM, IBERCOM IP, CORPORATE IP ALOJADO, IBERCOM IP EN RED, GATEWAY

NGN):
FRANQUEO
RESPONSABLE LOCALIZACIÓN CAUSA DETALLE
SIRIO
ASESORAMIENTO CLIE – EQTC – Asesoramiento a cliente.
A CLIENTE ASES Equipo terminal, accesorio o funcionalidad no compatible.
MALA CLIE – EQTC - Rotura del equipo terminal debido al mal uso por parte del
EQUIPO TERMINAL OPERACION CLIE cliente, no se incluye el desgaste por un uso normal.
DE CLIENTE
DEVOLUC.AVERIA CLIE – EQTC - Equipo terminal, acceso o funcionalidad no contratada
NO PROCEDENTE DVOT (encaminar a provisión), o no corresponde con el servicio.
VANDALISMO / CLIE – EQTC - Acciones de vandalismo o robos sobre los equipos terminales en
ROBOS CLIE cliente
ASESORAMIENTO CLIE – MRAI – Asesoramiento a cliente. La centralita, no tiene una funcionalidad
CLIENTE A CLIENTE ASES que satisfaga la necesidad del cliente.
Funcionalidad de la centralita no contratada (encaminar a
DEVOLUC.AVERIA CLIE – MRAI –
provisión), o no corresponde con el servicio. Mala operación de
NO PROCEDENTE DVOT
cliente, o hardware sin mantenimiento Ibercom.
CENTRALITA
PROBLEMA OPER – MRAI –
IBERCOM/SRC Problemas con el software instalado en equipos de cliente.
SOFTWARE CONF
CONFIGURACIÓN Reconfiguración por CEX de facilidad o extensión: extensiones,
DESDE EL No se abre nombre, apellidos, número DDI, desvío, transferencias,
CENTRO DE SIRIO conferencias, no molestar, plan de llamadas entrantes, captura
GESTION de llamadas. Modificaciones no Facturables (repro R1).
Edición 1.8
Página 111 de 155

VANDALISMO / CLIE – MRAI –

N/A en CentrexIP, ni SBC Virtual.
ROBOS CLIE
PRUEBAS No se abre Para registrar los casos en los que el cliente declina realizar las
RESPALDO SIRIO pruebas de respaldo, aportando la solicitud del cliente.
ASESORAMIENTO CLIE – APGM - Asesoramiento a cliente. La centralita no tiene una funcionalidad
A CLIENTE ASES que satisfaga la necesidad del cliente
Desconfiguración de los servicios de valor añadido por causa
MALA CLIE – APGM –
APL/PROD VALOR cliente: buzón de voz, grabador, informe de llamadas,
OPERACION CLIE
AÑADIDO EN comunicaciones unificadas, aplicación recepcionista.
GARANTIA MANT Servicio de valor añadido no contratada (encaminar a provisión) o
DEVOLUC.AVERIA CLIE - APGM – no corresponde con el servicio CentrexIP: buzón de voz,
NO PROCEDENTE DVOT grabador, informe de llamadas, comunicaciones unificadas,
aplicación recepcionista.
FALLO ELÉCTRICO
/ FALTA FLUIDO CLIE – EACE - Fallo eléctrico en infraestructura de cliente: cortes, obras,
DOMICILIO / DOMICILIO VOLT excavaciones…
INFRAESTRUCTURA CLIENTE
/SERVICIOS Para incidencias locales en las que el cliente ha demorado la
Cliente demora la
CLIENTE No se abre atención en un tiempo superior a 48 horas laborables, y que tras
atención de la
SIRIO este período la incidencia no se ha resuelto o el diagnóstico inicial
incidencia
es erróneo.
MALA No se abre Por ejemplo, avería en una línea de otro operador que por error
OPERACION SIRIO nos las abren a nosotros.
PROVEEDOR
SERVICIOS FALLO ELÉCTRICO
CLIENTE / FALTA FLUIDO No se abre El cliente se queda sin suministro eléctrico por culpa del
DOMICILIO SIRIO suministrador.
CLIENTE
Sustitución de terminal: Se ha tenido que cambiar el terminal por
uno nuevo (ya sea fijo, dect, antena dect, analógico o adaptador
de terminal analógico)
Sustitución o reparación de un componente del terminal: Se ha
PROBLEMA OPER – EQTC –
tenido que sustituir o reparar un componente de un terminal
HARDWARE COMP
(cable rizado, batería, micrófono, altavoz…)
Sustitución o reparación de accesorios: Se ha tenido que sustituir
o reparar un accesorio del terminal (auricular cableado, auricular
EQUIPO TERMINAL bluetooth, módulo de teclas…)
DE CLIENTE
PROBLEMA OPER – EQTC –
Problemas con el firmware del terminal.
SOFTWARE COMP
Problemas en los equipos terminales debido a operaciones
MALA OPER – EQTC –
realizadas por Telefónica: (cambio de plantillas, actualizaciones
OPERACION TRAU
masivas, subida de versión, trabajos programados…)
Desaparecida después de realizar pruebas, dejar en observación
TELEFÓNICA OPER – EQTC –
DESAPARECIDA aunque apunta a esta localización no se ha podido determinar la
DESA
causa.
Servidor caído o componentes (placa, tarjeta…) del servidor
PROBLEMA OPER – SERV –
caídos. En CentrexIP hace referencia a las plataformas Web
HARDWARE ERHW
CentrexIP, Grabador, Aplicación Recepcionista…
Problemas de software en centralita o reconfiguración por CdS de
PROBLEMA OPER – MRAI – facilidad o extensión: extensiones, nombre, apellidos, número
SOFTWARE CONF DDI, desvío, transferencias, conferencias, no molestar, plan de
CENTRALITA llamadas entrantes, captura de llamadas.
IBERCOM/SRC
CONFIGURACIÓN
DESDE EL No se abre
Reconfiguración por CEX cuando sea por avería.
CENTRO DE SIRIO
GESTION
PROBLEMA OPER – MRAI – Problema en el acceso, circuito, SRC, GW, o en las redes de voz
ACCESO CONF NGN, PSTN (Fijo), PLMN (Móvil), ISDN (RDSI).
Edición 1.8
Página 112 de 155

Desaparecida después de realizar pruebas, dejar en observación,

OPER – MRAI –
DESA
causa.
No se abre
AVERÍA MASIVA Informar de la incidencia masiva.
SIRIO
PRUEBAS No se abre
Para registrar las pruebas de respaldo realizadas.
RESPALDO SIRIO
Problemas de software en las aplicaciones o productos de valor
PROBLEMA OPER – APGM
añadido: buzón de voz, grabador, informe de llamadas,
SOFTWARE - ERSW
comunicaciones unificadas, aplicación recepcionista...
CONFIGURACIÓN
APL/PROD VALOR Reconfiguración por CEx en servicios de valor añadido: buzón de
DESDE EL No se abre
AÑADIDO EN voz, grabador, informe de llamadas, comunicaciones unificadas,
CENTRO DE SIRIO
GARANTIA MANT aplicación recepcionista
GESTION
Desaparecida después de realizar pruebas, dejar en observación,
OPER – APGM
- DESA
causa.
Si tras la revisión de la configuración de los servicios de
NO EXISTE No se abre conectividad solicitada por algún área interna de Telefónica (CdS
PROBLEMA SIRIO o instaladores) se verifica que todo está correcto y no es
necesario realizar ningún cambio.
EDC - ROUTER Modificaciones no facturables solicitadas por CdS realizadas
CONFIGURACIÓN sobre los EDCs del servicio de conectividad.
DESDE EL No se abre Configuraciones realizadas en el EDC del servicio de conectividad
CENTRO DE SIRIO tras una revisión de los equipos solicitada por los CdS o el
GESTION instalador del servicio de voz.
6.6.2 INCIDENCIAS CON CAUSA SOLUCIÓN/CIERRE “FALLO ELÉCTRICO / FALTA

FLUIDO EN DOMICILIO DE CLIENTE”
Debido al volumen de incidencias de este tipo, se debe prestar más atención a la hora de proceder al
cierre de estas incidencias.
En los servicios de DATOS, se diferenciará si el problema ha estado provocado por cliente por una
deficiencia o manipulación en su instalación eléctrica (localización:
Domicilio/Infraestructura/Servicios de cliente), o por el contrario si el fallo ha estado provocado por
la compañía eléctrica que proporciona el servicio al cliente (localización: Proveedor servicios cliente).
Si el fallo eléctrico ha sido en el domicilio de Cliente, nunca deberá imputarse la responsabilidad a

Telefónica, ya que en todo momento cliente está obligado a proporcionar el correcto suministro
eléctrico a los equipos de Telefónica.
Sólo en aquellos casos en los que la incidencia ha tenido lugar en dependencias de Telefónica
(Central, TIC, etc.) se podrá cerrar la incidencia como Responsable Telefónica.
6.6.3 INCIDENCIAS REPETIDAS
Se debe evitar al máximo posible la existencia de incidencias repetidas. Estas incidencias son las
producidas sobre el mismo elemento [Valor Identificador] en un plazo menor de 30 días.
Edición 1.8
Página 113 de 155

La mejor manera de evitar las incidencias repetidas es no cerrar nunca una incidencia si no está
garantizada su solución. Es preferible dejarla en Observación.
6.6.4 INCIDENCIAS MASIVAS
En todo momento ante la recuperación de la conectividad se podrá contrastar la información

publicada y en el caso de existir recuperación del servicio se procederá al consiguiente paso a estado
RESUELTA de toda aquella incidencia asociada al INC Masiva con independencia de esperar a su
cierre definitivo en sistemas.
Si con el cierre de la incidencia el servicio no se reestableciera, el CEX debe abrir un SIRIO indicando
que ese circuito afectado por la INC-XXXXXXXXXX y que tras la resolución de esta el circuito de
nuestro cliente no ha recuperado.
Si la incidencia recupera con la masiva, en la solución se indicará Causa: Avería Masiva.
El CEX actuará como el interlocutor técnico del cliente de cara al 2º Operador por lo que le
corresponden las siguientes funciones:
- Atender las llamadas del 2º Operador
- Colaborar con el 2º Operador en el diagnóstico de la incidencia
- Recepcionar el franqueo de la incidencia y realizar las pruebas de comprobación.
- El protocolo de pruebas a realizar con el 2º Operador se establecerá con el cliente por si

requiere acceso a algún elemento particular de la red de cliente.
- Dar el visto bueno al 2º Operador de la incidencia resuelta.
- De forma delegada el CEX gestionará con el 2º Operador los ANSs y escalados acordados por
el cliente con el 2º Operador (ver apartado específico).
Edición 1.8
Página 114 de 155

6.7 A10 - CONFIRMACIÓN DE CIERRE
Esta actividad hace referencia al cierre formal y definitivo de la incidencia, una vez concluidas las
tareas de la actividad de resolución en la cual se ha solucionado el problema que afectaba al servicio,
y de ser necesario se ha mantenido en observación para asegurarnos de que la reparación ha surtido
el efecto deseado y no se ha vuelto a reproducir el problema.
Una vez llegados a este punto, solo nos queda pedir la conformidad del cliente con la resolución y
cierre de la incidencia mediante la realización y registro en el ticket de GDIA del contacto de cierre
según lo definido en el ANEXO 2: PLAN DE COMUNICACION A CLIENTE, con el objetivo de obtener su
conformidad sobre la acción correctiva aplicada sobre el servicio o activo afectado, mediante la
realización de comprobaciones por parte de cliente en sus sistemas o comunicaciones con la ayuda
de los usuarios finales. Debemos asegurarnos de que el contacto de cliente que nos dé la
conformidad sea el que aparece como contacto de cliente en los datos generales de la incidencia.
Una vez franqueada la incidencia con el 2º Operador se procederá a cerrar la misma en GDIA,
informando de la resolución y se desencadenará el procedimiento informativo habitual con el cliente.
La Causa en el cierre independientemente de la información recogida en el registro, será

Responsable CLIENTE.
El CEX de forma delegada va a gestionar los ANS y escalados con el 2º Operador para la resolución de
incidencias, por lo que tiene que estar en disposición de reclamar las incidencias no resueltas o no
conformes al 2º Operador.
TdE y por tanto el CEx/CGE no es responsable de los ANS del 2º Operador, pero sí de su gestión, en
ese sentido para una incidencia con el 2º Operador está vigente la matriz de escalados entre TdE y el
cliente.
Edición 1.8
Página 115 de 155

7 A11 - GESTIÓN DE PROBLEMAS

En esta actividad se realiza el análisis del histórico de incidentes y la evaluación de la información
disponible, incluyendo tendencias y otros patrones, con el objetivo de solucionar incidencias
reiteradas o escalar y solucionar problemas que afectan a volúmenes agregados de incidencias.
El objetivo de esta actividad es el de realizar un análisis exhaustivo para buscar la causa raíz de una
incidencia cuando se identifica que es reiterada, es decir, se repite en el tiempo con un patrón común
con otra/s. Es obligatorio realizar esta actividad sobre incidencias repetidas donde la causa de
repetición sea la misma que en la anterior ocurrida sobre el mismo elemento.
Una incidencia se considera repetida si ha ocurrido otra incidencia sobre el mismo circuito en un
plazo menor de 30 días. El número de repeticiones y averías de los últimos 30 días puede consultarse
en GDIA (en el resumen de la incidencia con el histórico de averías anteriores al seleccionar).
Es importante tratar de minimizar el número de incidencias repetidas siguiendo los siguientes pasos:
Al inicio del tratamiento de una incidencia, independientemente del origen de esta

(proactiva, cliente, etc.), se debe comprobar si ha tenido averías recientes. En caso afirmativo se
revisarán las acciones tomadas previamente y se tendrá en cuenta esta información para tratar la
nueva avería.
En aquellos casos en los que tras la recuperación del servicio exista una duda razonable sobre
si el problema ha sido realmente resuelto, debemos informar al cliente sobre la recuperación del
servicio y que lo tendremos en observación para mayor garantía unas horas, y mantendremos la
incidencia en observación un máximo de 48 horas laborables a propuesta del CEx, o 7 días naturales
en los casos en los que lo solicite el cliente, antes de proceder al cierre. En GDIA registraremos el
contacto “mantener en Observación” que automáticamente cambiará el estado de la incidencia a “En
Observación-Verificación”, y ante contingencias de GDIA o servicios cuya gestión no se realiza en este
sistema registraremos un contacto de resolución y se modificará el estado a “En Observación-
Verificación” manualmente.
En los casos reiterativos de detección de incidencias en los que la responsabilidad sea del
cliente, (por ejemplo: apagado diario del router por parte del cliente), debemos informarle y
proponerle acciones de mejora concretas explicándole las consecuencias derivadas como posibles
averías en el EDC.
Además, para el servicio RPV Internacional, dependiendo de la complejidad del problema, se debe
realizar lo descrito en la operativa Guía de Gestión de Problemas.
Edición 1.8
Página 116 de 155

8 A12 - EJECUCIÓN DE OPERACIONES DE MANTENIMIENTO PREVENTIVO Y

CORRECTIVO
Esta actividad recoge la ejecución de tareas rutinarias que conllevan acciones para el mantenimiento
preventivo y correctivo de los componentes de la infraestructura de comunicaciones y aplicaciones
relacionadas con los servicios, como pueden ser la realización de pruebas de contingencia de los
circuitos o equipos de backup o secundarios, revisión de configuraciones, ejecución de roll-outs de
SW, entre otras. Todo ello relacionado con la gestión y seguimiento del servicio de mantenimiento.
Estas tareas se realizarán con el objetivo de mantener los componentes de los servicios en
condiciones óptimas de operación para garantizar la prestación de un nivel adecuado del servicio al
cliente y prevenir o adelantarse a posibles problemas o fallos que se puedan presentar más adelante.
Para dejar constancia de los trabajos de mantenimiento preventivo (pruebas de redundancia o

backup) se registrará un máximo de una incidencia por Cliente cada mes, en la cual se detallarán:
Las sedes probadas.
Los Clientes asociados a dichas sedes.
Las pruebas que se han realizado (total o parcial, con corte a cliente o sin corte…) y
documentación asociada debiéndose adjuntar un fichero en la pestaña documentos que recoja el
detalle de las sedes o líneas probadas para cada Cliente.
Esta incidencia deberá registrarse como Incidencia local y con los siguientes parámetros:
Vía: ProActivo por Rutina.
Fase: Explotación
Síntoma: Actuaciones Preventivas de mantenimiento (para los servicios que no tengan

contemplado este síntoma se abrirá con el síntoma Otros).
Diagnóstico: EDC - Actuaciones Preventivas de mantenimiento.
Descripción Apertura / Cierre: Pruebas rutinarias de backup
Cierre: Telefónica – EDC-Router o CENTRALITA IBERCOM/SRC – Pruebas Respaldo
En aquellos casos en los que el cliente declina realizar las pruebas (para una sede o un conjunto de
sedes), deberá registrarse como Incidencia local y con los siguientes parámetros:
Fase: Explotación
Edición 1.8
Página 117 de 155


Descripción Apertura: Pruebas rutinarias de backup
Descripción Cierre: Cliente no autoriza la realización de las pruebas rutinarias de backup
Cierre: Cliente – EDC-Router o CENTRALITA IBERCOM/SRC – Pruebas Respaldo
En este caso será necesario adjuntar el mail en el que el cliente declina que el CEx realice las
pruebas de backup a la incidencia.
Para las actualizaciones de SW o certificados (por ejemplo, iAPs WIFI), mismas pautas indicadas
anteriormente registrando un nuevo ticket GDIA como LOCAL con los siguientes parámetros.
Aclaración: NO es preciso un ticket por iAP o equipo actualizado, sino un ticket que contenga un
Excel adjunto con todas las actualizaciones realizadas ese día.
Para la actualización de certificados:
Fase: Explotación

Descripción Apertura: Carga de Certificados WIFI iAPs
Cierre: Telefónica - EDC Punto de Acceso - Configuración desde el Centro de Gestión.
Descripción Cierre: Mantenimiento Preventivo.
Para la actualización de versión software:
Fase: Explotación


Edición 1.8
Página 118 de 155

Descripción Apertura: Actualización de versión software
Cierre: Telefónica - EDC-Router - Configuración desde el Centro de Gestión
Descripción Cierre: Mantenimiento Preventivo.
Si por requerimiento del cliente estas pruebas deben realizarse fuera del horario del CGE que no es
7x24 y no tiene contratada la extensión horaria a CEx Premium, en ningún caso esto se realizará por
el centro encargado del fuera de horas, sino que será necesario gestionar pedido comercial que
ampare la atención por parte del CGE responsable.
8.1 SERVICIOS DE DATOS
Para los servicios de datos se ha definido la realización de las siguientes pruebas de mantenimiento
preventivo.
- Pruebas de redundancia
Para los servicios de datos Macrolan, VPNIP y Datainternet (no aplica en LITE) se han definido las
pruebas que se deben realizar anualmente en la guía de pruebas de respaldos y balanceos disponible
en BTO.
- Actualizaciones de software/firmware
Actualizaciones de software/firmware cuando se homologa una nueva versión que puede ser
motivada por la detección de un bug de seguridad y/o funcionalidad, por la inclusión de mejoras en
el servicio o cualquier otro motivo.
- Actualización de certificados de los iAP

Actualización certificado de los iAPs de ARUBA necesario para el correcto funcionamiento del
servicio. Esta tarea es recurrente y se debe ejecutar anualmente y siempre antes de la caducidad de
este.
Se generará el nuevo certificado y se informará mediante Comunicado OR con una antelación mínima
de un mes.
- Cambios de configuración por actualización de plantillas

Ante actualizaciones de las plantillas que afecten al correcto funcionamiento del servicio, se pueden
recibir solicitudes de las áreas correspondientes para proceder con la actualización de la
configuración de los equipos. Estas solicitudes se reciben por comunicados vía correo.
8.2 SERVICIOS DE VOZ
Para los servicios de voz las pruebas de mantenimiento preventivo están definidas en las guías
operativas de estos servicios.
Edición 1.8
Página 119 de 155

- Pruebas de redundancia:
Las pruebas de redundancia son necesarias para poder asegurar un buen mantenimiento de la
solución de voz implantada en cliente.
Edición 1.8
Página 120 de 155

9 A13 - CAMBIOS DE CONFIGURACIÓN

Este apartado describe la operativa a seguir en esta actividad relacionada con los cambios de
configuración en los servicios, facilidades, o elementos que surgen dentro del ámbito de las tareas de
mantenimiento. Es decir, se excluyen las relacionadas con la provisión de los servicios, altas, bajas, o
modificaciones que suponen un coste adicional para el cliente. De esta forma los cambios de
configuración que se gestionan en esta actividad solo se corresponden con las modificaciones no
facturables (MNF) solicitadas por el cliente.
Es importante no confundir esta actividad con los cambios de configuración derivados de las
actividades de provisión, aunque el pedido esté finalizado, pero la puesta en servicio no ha sido
confirmada con el cliente y/o con el CdS, y se tratan con tickets en fase de provisión.
Dentro de las peticiones de cliente que pueden suponer cambios de configuración están las
Modificaciones Facturables (MF), y las Modificaciones No Facturables (MNF):
Modificaciones Facturables (MF): Son las peticiones/modificaciones de cliente que suponen

un coste, y que deben cursarse por el canal comercial y seguir el proceso de provisión de los
servicios, generándose pedidos y/u ordenes de provisión en los sistemas correspondientes.
o Altas: De servicios, facilidades, o elementos nuevos del catálogo de marketing. Por

ejemplo, el alta de un nuevo router y circuito VPN IP.
o Bajas: También pueden ser bajas de servicios, facilidades, o elementos que el cliente
ya tiene, pero que desea dar de baja. Por ejemplo, la baja de un primario RDSI que ya
tiene contratado.
o Modificaciones: Sobre servicios, facilidades, o elementos que el cliente ya tiene

contratados, y que suponen un cambio en la arquitectura, configuración o
especificación de lo que se encuentra en producción en ese momento. Por ejemplo,
la modificación de los caudales contratados en un circuito Macrolan.
Modificaciones No facturables (MNF): Son aquellas peticiones/modificaciones de cliente que

NO suponen un coste adicional. Se trata habitualmente de pequeños cambios en los servicios,
facilidades, o elementos, de bajo riesgo, bajo coste, y que ocurren frecuentemente. Se deben realizar
directamente las que están preautorizadas. Por ejemplo, cambiar el direccionamiento IP de una
VLAN en la LAN de cliente, o modificar el nombre de una extensión de usuario. Estas modificaciones
están tipificadas según servicio y trabajo a realizar.
Las modificaciones no facturables no tipificadas, el cliente debe solicitarlas al Comercial para

que solicite el correspondiente pedido.
Edición 1.8
Página 121 de 155

Las modificaciones podrán ser facturables o no, también dependiendo del servicio, por ejemplo, en
Ibercom IP para las altas y bajas de extensiones el cliente contrata un número de licencias al inicio, es
decir que el cliente puede dar de alta extensiones hasta que alcance el límite de licencias contratadas
sin coste adicional (Mantenimiento), pero a partir de ahí debe contratar más licencias que
supondrían un coste adicional (Provisión). Por otra parte, en los servicios Ibercom IP en Red (Centrex
IP) y CoIP Alojado, debido al modelo comercial de pago por uso, cada alta y baja de una extensión de
usuario supone un coste (Provisión). Por este motivo, se debe comprobar el listado de cambios de
configuración o reprogramaciones definido en las guías de cada servicio.
Esta actividad se debe registrar como Fase “Provisión” y Síntoma “Modificación No Facturable”, para
aquellas actuaciones derivadas de modificaciones no facturables solicitadas por el Cliente, sin pedido
LOGOS asociado, ligadas al EDC y centralitas (Por ejemplo: IP LAN, Rutas Estáticas, ACL, DHCP,
configuración de teclas, desvíos, asignación de DDI, etc.). Solo se deben hacer las que están
autorizadas y definidas en cada servicio.
Para todas las modalidades de gestión, el procedimiento a seguir para las Modificaciones No
Facturables está recogido en la guía Operativa de GDIA y en la guía de Soporte a las Modificaciones
No Facturables
Estas solicitudes/peticiones se cerrarán como:
Responsable: Cliente.
Localización: EDC- Router / Frad / TimeStep / Centralita.
Causa: Configuración desde el Centro de Gestión.
Comentarios: Breve resumen de la modificación realizada indicando los datos de la persona

que solicita dichos cambios.
No se podrán abrir como modificación aquellos cambios derivados de un problema en el servicio (por
ejemplo, lentitud ocasionada por QoS mal configuradas) que se resuelven modificando la
configuración del EDC.
Es importante documentar debidamente este tipo de peticiones, indicando claramente quién solicita
la Modificación, las causas y el trabajo realizado.
(*) Las Modificaciones No Facturables (MNF) son en cualquier caso una actividad de mantenimiento
asociada a la actividad “A13-Cambios de Configuración”, que deberá ser tratada según los
parámetros de cualquier actividad de mantenimiento, su registro como Fase “Provisión” es solo a
nivel de sistemas de ticketing.
Edición 1.8
Página 122 de 155

10 A22 - CONTROL DE INVENTARIO

El objetivo de esta actividad es la actualización y control del inventario de los elementos (CIs) que
componen los servicios gestionados (equipos, circuitos, servidores de llamadas, servidores de P/SVA,
terminales o extensiones, etc.), en los sistemas de control de inventario (CMDB). La información
relativa a los elementos deberá contener entre otros, sus atributos, características, y la relación entre
ellos dentro del sistema, plataforma, o servicio del que forman parte.
Los sistemas de control de inventario son LOGOS-PT para los servicios de datos, y CIBERUN para los
servicios de voz, como se detalla en las siguientes tablas:
LINEA
SERVICIO PROVISIÓN INVENTARIO
ACTIVIDAD
DataInternet LOGOS LOGOS-PT (automático)
Circuito punto a punto FAST, ATLAS

internacional
Circuitos punto a punto (nacional) ATLAS
Facilidad SILAN (TIC+ LAN) LOGOS LOGOS-PT (automático)
MacroLAN LOGOS LOGOS-PT (automático)
MetroLAN ATLAS LOGOS-PT (manual)
VPN IP LOGOS LOGOS-PT (automático)
FAST (Distribuidora), LOGOS LOGOS-PT (manual Distr.) y

VPN IP Internacional
(Prestadora) (automático Prest.)
DATOS
flexWAN LOGOS LOGOS-PT (automático)
Optimización de Aplicaciones en
RPVs
LOGOS (no admite altas ni LOGOS-PT (automático)

InterLAN
modificaciones)
(no admite altas ni LOGOS-PT

Frame Relay
modificaciones)
(no admite altas ni LOGOS-PT

Nodo de red
modificaciones)
Interconexiones de Fibra Directa ATLAS
Cloud Connect FAST LOGOS-PT (manual)
Edición 1.8
Página 123 de 155

LINEA
SERVICIO PROVISIÓN INVENTARIO
ACTIVIDAD
Voz CIBERUN / Datos LOGOS-PT

Facilidad Corporate IP Alojado Voz CIBERUN / Datos LOGOS
(automático)
Voz CIBERUN / Datos LOGOS (solo Voz CIBERUN / Datos LOGOS-PT

Ibercom (Tradicional, IP)
IIP) (automático)
Centrex IP (Ibercom IP en Red,

Voz CIBERUN / Datos LOGOS CIBERUN
MFEP, FlexUser)
VOZ
Acceso Primario Virtual (Ca NGN, Voz CIBERUN / Datos LOGOS-PT
Voz CIBERUN / Datos LOGOS
GW NGN) (automático)
Voz CIBERUN / Datos LOGOS-PT

Acceso único IP (AuIP, GW NGN) Voz CIBERUN / Datos LOGOS
(automático)
Accesos básicos RDSI CIBERUN CIBERUN
Accesos primarios RDSI CIBERUN CIBERUN
Para la mayoría de los servicios o elementos cuya CMDB es LOGOS-PT, los datos provienen del
sistema de provisión de los servicios de datos LOGOS. Una vez se finalizan los pedidos de provisión en
LOGOS, éstos actualizan la planta automáticamente en LOGOS-PT cargando los datos de las sedes,
equipos y accesos, servicios y centros. Si esta operación de volcado automático no hubiese
funcionado correctamente, primero se debe intentar relanzar el pedido desde el monitor de pedidos,
y si el problema persiste, se deberá abrir Argonauta ITSM para solicitar el volcado correcto de los
datos.
Para los servicios en los cuales la carga en LOGOS-PT se hace de forma manual, estos son los
responsables de ejecutarlo:
- Circuito punto a punto internacional: Lo realiza provisión internacional de forma proactiva.
- VPN IP Internacional (Distribuidora): Lo realiza provisión internacional de forma proactiva.
- Cloud Connect: Lo realiza provisión internacional de forma proactiva.
Es responsabilidad del CEx mantener actualizado el inventario de la planta en LOGOS-PT . Además,

para los equipos monitorizables, es decir aquellos que tienen una IP de gestión alcanzable desde el
sistema de gestión, es necesario que estén correctamente actualizados para su importación y
activación en el sistema de monitorización WOCU, así como su configuración y activación en el
sistema automatizado de diagnóstico y apertura de tickets ASTRO.
Edición 1.8
Página 124 de 155

La mayoría de los cambios en la planta de LOGOS-PT se pueden realizar con el perfil de

“ESCRITURAPLANTA”. La operativa para realizar una modificación en LOGOS PT está recogida en la
guía de LOGOS-PT.
El documento adjunto recoge el detalle de qué campos son modificables desde CEx, qué modalidad
de atención es responsable de esa modificación, cuál es la fuente de origen del dato, cuales son
solicitantes autorizados de una modificación y cómo se registra en sistemas corporativos la actividad
de Actualización de CMDB
Cuando surja la necesidad de modificación de la CMDB bien por petición de cliente o área interna
solicitante, bien por descubrimiento del CEx/CGE de información incompleta/incorrecta se deberá
registrar esa actuación mediante un ticket en GDIA con los siguientes parámetros:
- Servicio: Si la modificación aplica a un servicio se indicará este. Si es a nivel general de la sede se

indicará sobre el servicio principal de datos
- Fase de servicio: Provisión
- Vía: CACE - Si la petición llega de un área de TdE.
Proactiva por rutina: Surge la necesidad en el CEx/CGE
Correo/Teléfono - La petición llega del cliente
- Síntoma: MODIFICACIÓN CMDB
- Descripción: Indicar qué campos se han ejecutado en LOGOS PT, el motivo y solicitante que puede
ser: CEx/CGE, Cliente o Figura Telefónica
- Datos de Contacto: Datos del solicitante. Si es el CEx o Área Interna se registran nombre y teléfono
- Diagnóstico: Servicios DATOS: EDC - Posible problema de configuración
Servicios Voz: EDC-Posible problema de configuración del router / frad / timestep /
centralita
- Cierre: Tras la modificación se cerrará como:
o Causa: Configuración desde el centro de gestión
o Localización: Otra
o Responsable: Cliente o Telefónica
Es importante no confundir esta actividad con los cambios en la CMDB derivados de las actividades
de mantenimiento o provisión que se tratarán dentro de los propios tickets de provisión o incidencia
Edición 1.8
Página 125 de 155

Para los servicios de voz el sistema de inventario de planta es CIBERUN. Adicionalmente, en el caso
de servicios o soluciones convergentes, como por ejemplo los servicios que utilizan la RPV de datos, o
las comunicaciones unificadas (datos, voz fija, voz móvil), algunos datos, elementos, o características,
estarán contenidas en otros sistemas y se pueden consultar, como es el caso de LOGOS-PT para los
EDCs del servicio de conectividad de primer nivel, GW NGN, SBCs, Servidores de llamadas, SVAs,
marcado de servicio y/o facilidad; COGS para la parte de telefonía móvil (P/SVAs, solo para IIPR), e
INDICO que permite ver las extensiones de IIPR mediante el cruce de datos que hace entre CIBERUN
y LOGOS-PT.
En el caso de CIBERUN, los datos provienen de los sistemas de provisión de los servicios de voz,
principalmente de BJ, que es el sistema que se utiliza para la provisión de estos servicios. Una vez
finalizado el proceso de provisión y las órdenes de BJ, se vuelcan automáticamente a CIBERUN los
datos de los clientes, sedes, RAIs, centralitas, terminales, extensiones, SRCs, P/SVAs, funcionalidades,
etc.
Para esta actividad en los servicios de voz se hará lo dispuesto en las guías operativas de los servicios.
Actualmente el CEx/CGE, en todas sus modalidades de gestión, no es responsable del control del
inventario de la planta de voz en CIBERUN, pero sí de los elementos de voz inventariados en LOGOS
PT.
Para consultas de la planta de voz específicas, si el dato requerido no está disponible en CIBERUN,
debe trasladarse la necesidad al CDSVOZ a través de soporte y usando el procedimiento definido de
escalado TSO.
10.1 ACTUACIONES DE REGULARIZACIÓN ANTE BAJAS /PRE-BAJAS DE EQUIPOS
El Servicio CEx/CGE es responsable del actualizado de la planta en la CMDB LOGOS-PT.
Para los servicios cuyas peticiones de Alta/Baja/Modificación se gestionan mediante pedidos

comerciales SGC/LOGOS, en el momento de gestionar una BAJA de sede, equipo, y/o circuito, deberá
existir siempre un pedido LOGOS para gestionar la retirada del EDC, proporcionando por parte del
CEx/CGE un código de validación al técnico encargado de su retirada.
Una vez finalizado el pedido LOGOS, esa información debería quedar actualizada de forma
automática en la planta de LOGOS-PT, mediante la eliminación de las sedes, equipos, y/o circuitos
asociados a la BAJA.
Sin embargo, detectamos que en determinadas ocasiones la sincronización automática entre

sistemas falla, y existen pedidos de LOGOS con BAJAS finalizadas sin reflejo correcto en LOGOS-PT, y
por consiguiente tampoco la eliminación de la monitorización en WOCU del EDC.
Por tanto, las acciones a realizar por parte del CEx/CGE son:
Si el CEx/CGE detecta que se dan estas condiciones:
o Pedido LOGOS con Movimiento BAJA finalizado en LOGOS.

Edición 1.8
Página 126 de 155

o Equipos y/o circuitos presentes en LOGOS-PT, y/o EDC presente en Reino WOCU del
CEx/CGE al cual pertenecía.
Acciones a realizar:
o Confirmar que no existe otro pedido posterior de ALTA que invalide al pedido de
BAJA detectado.
 Si existe un pedido posterior de ALTA, el EDC ha de seguir estando en la

CMDB y en WOCU.
 Si no existe pedido posterior de ALTA, aplica el pedido LOGOS de BAJA
detectado debiendo realizar el CEx/CGE:
 Eliminar los equipos y/o circuitos de LOGOS-PT de forma manual
(acción posible con el perfil ESCRITURAPLANTA).
 Una vez eliminado el EDC de LOGOS-PT, acceder al reino WOCU del
CEx/CGE y eliminar dicho EDC desde el menú IMPORT TOOL.
o Pedido LOGOS con Movimiento BAJA “En curso en LOGOS, pero aún no finalizado,
aunque con constancia de EDC desconectado de la corriente eléctrica”.
o EDC presente en LOGOS-PT y/o EDC presente en Reino WOCU del CEx/CGE al cual
pertenecía.
o Hay que confirmar que no existe otro pedido posterior de ALTA que invalide al
pedido de BAJA detectado.
 Si existe un pedido posterior de ALTA, los equipos y/o circuitos han de seguir
estando en la CMDB, y el EDC en WOCU.
 Si no existe pedido posterior de ALTA, aplica el pedido LOGOS de BAJA
detectado debiendo realizar el CEx/CGE:
 Mantener el equipo y/o circuito en LOGOS-PT hasta que finalice el
pedido, aunque actuando sobre el EDC modificando estos campos en
Equipo/Gestión de forma individual gracias al perfil
ESCRITURAPLANTA.
o Proactividad: NO requiere la funcionalidad
o Plataforma Automática Apertura Tickets: Deshabilitada
o Est. Gestión Especial: PREBAJA
 Acceder al reino WOCU del CEx/CGE y eliminar dicho EDC desde el
menú IMPORT TOOL.
 En el momento que el pedido de BAJA ya esté finalizado, revisar si el
EDC ya ha desaparecido de LOGOS-PT, y en caso contrario actuar
según lo indicado en el punto 1).
Edición 1.8
Página 127 de 155

o NO existe Pedido LOGOS con Movimiento BAJA, aunque tenemos constancia de EDC
desconectado de la corriente eléctrica con confirmación de baja real por parte de
cliente.
pertenecía.
o Comprobar que realmente no existe pedido de BAJA en Sistemas.
 Si existe un pedido en Sistemas ya finalizado, actuar de acuerdo con lo
indicado en el punto 1).
 Si existe un pedido en Sistemas “En curso aún sin finalizar”, actuar de
acuerdo con lo indicado en el punto 2).
 Si no existe pedido comercial de BAJA (ni finalizado ni en curso):
 Informar de la situación a Comercial / Gestor de Servicio para que
realicen las acciones oportunas a nivel de pedido comercial de BAJA.
 Mantener el EDC en LOGOS-PT hasta que finalice el pedido, aunque
actuando sobre él modificando estos campos en Equipo/Gestión de
forma individual gracias al perfil ESCRITURAPLANTA.
o Proactividad: NO requiere la funcionalidad
o Plataforma Automática Apertura Tickets: Deshabilitada
o Est. Gestión Especial: PREBAJA
o Observaciones Gestión: Especificar “BAJA PENDIENTE
TRAMITAR".
 Acceder al reino WOCU del CEx/CGE y eliminar dicho EDC desde el
menú IMPORT TOOL.
 En el momento que el pedido de BAJA ya esté finalizado, revisar si el
EDC ya ha desaparecido de LOGOS-PT, y en caso contrario actuar
según lo indicado en el punto 1).
o NO existe Pedido LOGOS con Movimiento BAJA, aunque tenemos constancia de EDC
desconectado de la corriente eléctrica con confirmación de “NO BAJA, simplemente
APAGADO TEMPORAL por motivos COVID, vacacionales, obras de cliente, otros
similares”.
pertenecía.
o Mantener el EDC en LOGOS-PT dado que es un EDC en planta de mantenimiento,
aunque actuando sobre él modificando estos campos en Equipo/Gestión de forma
individual gracias al perfil ESCRITURAPLANTA.
 Proactividad: NO requiere la funcionalidad
Edición 1.8
Página 128 de 155


Plataforma Automática Apertura Tickets: Deshabilitada entre fechas
(especificar las fechas)
 Est. Gestión Especial: NO ACTIVO
 Observaciones Gestión: Especificar “APAGADO TEMPORALMENTE
POR MOTIVOS XXXXXXXXX (especificarlos)".
o En el momento que tengamos confirmación de que el EDC vuelve a estar operativo
(ya ha finalizado esa circunstancia especial); revertimos los pasos indicados
anteriormente.
10.1.1 RECOMENDACIONESDE ACTUACIÓN EN CEX (ESTANDAR) Y CEX AVANZADO
Así como en CEx Premium y CGE es bastante factible que tengamos un correcto control de la planta
con nuestro cliente, en otras modalidades como CEx o CEx Avanzado no existe esa interacción con
cliente, y a veces es complicado poder tener una planta actualizada en la CMDB.
Por ese motivo, y con el objetivo de facilitar las acciones de Control de Planta al CEx, recomendamos
una especial atención desde WOCU a aquellos EDCs que presentan estado DOWN, y que tienen el
campo “active_check_enabled = 0”; información descargable en formato CSV desde el Menú ASSETS
– CSV.
Es muy posible que esos EDCs sean bajas reales no regularizadas correctamente en la CMDB LOGOS-
PT, ni en WOCU, siendo éstos EDCs en los que principalmente deberemos realizar las
comprobaciones especificadas en el subapartado anterior.
Edición 1.8
Página 129 de 155

11 A23 - INVENTARIADO DE CONFIGURACIONES

En esta actividad se llevan a cabo tareas relacionadas con la obtención y actualización de la
información de las configuraciones de los equipos de los servicios, necesarias para su correcto
funcionamiento y prestación.
El CEx/CGE será responsable de realizar esta actividad sobre aquellos servicios que la tengan
integrada. En el menú de Gestope "Configuraciones-Repositorio" están accesibles las copias de
backup de las configuraciones sobre los EDCs de planta gestionada en los servicios de Datos. En el
supuesto de identificar cualquier problema de volcado de configuraciones en el repositorio, el
CEx/CGE deberá asegurarse de que los EDCs disponen de las últimas configuraciones estándar
especificadas en las plantillas del servicio, y realizar una subida manual de la configuración desde
Gestope.
El CEx/CGE será responsable de verificar que se dispone de copias de la configuración actual de los
equipos en los sistemas o servidores, necesarias para las tareas de mantenimiento, para que en caso
de avería poder disponer de manera inmediata de la última configuración operativa del equipo
afectado, y poder proceder con su sustitución (en caso necesario), configuración, y puesta en marcha
en el menor tiempo posible, para recuperar cuanto antes el servicio prestado al cliente. En caso de
que no esté almacenada dicha configuración correctamente, es su responsabilidad verificar la
configuración del equipo o/y abrir incidencia a sistemas para que se revise.
Las copias de las configuraciones de los equipos pueden estar en los siguientes sistemas,
plataformas, o servidores/equipos:
- Servicios de datos:
o GESTOPE: Repositorio de las configuraciones de los EDCs.
o PLATAFORMA SERVICIO: Para los servicios cuyos EDCs tienen el plano de control
centralizado, es decir que no está en el propio equipo en el domicilio de cliente, sino
que está alojado en la red en los CDGs de TE, como es el caso del servicio FlexWAN
(Portal, Orquestador, VSD y VSC).
- Servicios de voz:
o GESTOPE: Repositorio de las configuraciones de los EDCs GW NGN (APV y AuIP).
o CENTRALITA/CALL SERVER: Copias de la configuración en distintas particiones de las

propias centralitas o call servers, y replicaciones en ambos servidores en soluciones
redundadas.
o PLATAFORMA SERVICIO: Para los servicios en los cuales la centralita o call server está
alojada en la red en los CDGs de TE, como es el caso de los servicios Corporate IP
Alojado, e Ibercom IP en Red/Centrex IP.
Edición 1.8
Página 130 de 155

Los CEx/CGE deben asegurarse de que se estén haciendo las copias automáticas de las
configuraciones, realizando las actuaciones definidas para cada servicio, y en el caso de que no se
estén realizando, aplicar las acciones correctivas definidas o solicitar al grupo correspondiente para
que se realicen las copias de seguridad de la configuración.
Edición 1.8
Página 131 de 155

12 A24 - REPORTING
Elaboración de información de reporting sobre los servicios incluyendo procesos de provisión,
mantenimiento, pedidos, incidencias singulares, niveles de servicio, facturación e inventario. Como
esta guía solo hace referencia a las tareas y actividades de los servicios integrados en CEx, aplican
solamente las relacionadas con el reporte a cliente definido para estos servicios.
Esta información que se aporta al cliente como parte de la operativa de la gestión de sus servicios, se
puede hacer de manera proactiva, o en respuesta a una petición expresa de cliente. Dentro de esta
información podría estar un reporte del estado de la red, incidencias singulares o masivas, niveles de
servicio, inventario de planta, puertos libres de un equipo, tráfico de los caudales utilizado de un
circuito, funcionalidades contratadas, etc, y según lo definido para cada servicio. Los informes
pueden ser estándar, avanzados o personalizados, y aplicarán dependiendo de la modalidad de
gestión y lo contratado por el cliente.
Para los servicios MACROLAN, VPNIP, DATAINTERNET (incluido LITE) y RPV INTERNACIONAL; la
herramienta homologada para elaboración de los informes mensuales de servicio que han de
presentarse al cliente es PIP. Para los servicios integrados en CEx que tengan definidos informes, el
sistema a utilizar para obtenerlos y la operativa a seguir estará descrita en las guías operativas
correspondientes.
12.1 HEALTH-CHECK DIARIO
El envío diario de Health - Check es una actividad de "Seguimiento" (independiente a la actividad de

Reporting mensual) sobre las incidencias activas de los servicios gestionados, pero para una mejor
comprensión de su naturaleza queda incluido en este apartado de la guía operativa dado que es un
reporte diario a cliente.
Con el objetivo de ofrecer a nuestros clientes un mejor servicio de seguimiento - monitorización de

sus accesos y básicamente, un estado real de “Salud de su Red”, surge esta iniciativa que aplica a las
siguientes tipologías de centros:
- CEx Premium
- CEx Premium +
- CGE
De forma diaria, deberá remitirse el siguiente email de seguimiento desde el buzón genérico de
Operación del Centro.
Alcance y Escalados:
Aplica a las siguientes tipologías de servicios:
- Servicios de Comunicaciones (Datos / Voz).

- Servicios TI (LAN + VCF).
- Servicios Cloud (solo aplica en la parte de SSPP – Servicios Personalizados).
Edición 1.8
Página 132 de 155

Para la parte de Comunicaciones, los CEx/CGE deberán obtener la información desde los
sistemas/herramientas de ticketing para los servicios de datos y voz GDIA.
Para la parte de TI (LAN+VCF), existe una automatización mediante la cual el CEx/CGE CEx/CGE
CEx/CGE recibirá toda la información necesaria (listado de incidencias pendientes) vía email antes de
las 10:00h desde la herramienta AURORA [mailto:dstsol.cdg.sso.sgi@telefonica.es].
En el supuesto de que los CEx/CGE no reciban la información necesaria para la parte de informe TI,
podrán obtener directamente la información consultando en WT/SGSD o Remedy, y procederán a
escalárselo a la OTE GPT (GTTI) en el mail TSO_GT Explotación GPT.
Para la parte de los servicios CLOUD, dado que son servicios NO gestionados hoy en día por parte de
los CEx/CGE, dichos centros recibirán la información necesaria para el email / informe desde el CdS
Cloud (SSPP Cloud) de forma diaria antes de las 10:00h reflejando el estado de “Salud de Red” de los
servicios contratados por el cliente.
En el supuesto de que los CEx/CGE no reciban la información necesaria para la parte del informe
CLOUD, deberán contactar con el CS SSPP Cloud:
DS_TSOL_SSPP ADMTI sspp.admti@telefonica.com
Tiempos y Envío del Informe:

EMAIL DIARIO HEALTH CHECK ENVIADO DESDE EL CEx/CGE A PRIMERA HORA DE CADA MAÑANA
Hora envío:
- Nunca en horario posterior a las 10:30h.

- El envío lo realizará el servicio de Operación del Servicio CEx/CGE.
Contenido y Estructura del informe:

CABECERA DEL EMAIL
PARA: <Interlocutor autorizado de cliente>
CC: GdST (Gestor de Servicio Técnico); GdS (Gestor de Servicio)
ASUNTO: <CEx XXXX> Health Check diario <dd-mm-aaaa>
CONTENIDO DEL EMAIL

Buenos días <Interlocutor autorizado de cliente>
Adjunto enviamos el informe diario del estado actual de sus servicios:
Edición 1.8
Página 133 de 155

Estado de los SERVICIOS/SEDES/CIRCUITOS CRÍTICOS con posible impacto en

el Negocio (*).
ID TICKET
ENTIDAD ID TICKET
HERRAMIENTA CEx
ESTADO HERRAMIENTA SERVICIO SEDE
CLIENTE CLIENTE
(GDIA)
Nombre
1234-CAMPO DE
Cliente o UP MLAN CPD1
LAS NACIONES
subcliente
Nombre
5678-JULIÁN
Cliente o UP MLAN CPD2
CAMARILLO
subcliente
(*) Aplica únicamente a los circuitos críticos identificados / marcados en sistemas en cada cliente del
CGE / CEx.
TODAS las Incidencias activas y en resolución de los siguientes servicios:
Servicios COM
ID TICKET
ENTIDAD ID TICKET HERRAMIENTA
BREVE DESCRIPCIÓN FECHA
HERRAMIENTA CEx SERVICIO SEDE ESTADO
INCIDENCIA APERTURA
CLIENTE CLIENTE
(GDIA)
En Curso.
Nombre Indicad, Síntoma de Técnicos
8013- 08-11-2018
Cliente o No Procede 199999 MLAN Incidencia trabajando en
EIBAR 12:15h
subcliente restauración
del servicio.
Servicios TI
Las incidencias de servicios TI se envían en una tabla independiente, de acuerdo con la

información (y misma estructura) recibida desde Aurora:
Edición 1.8
Página 134 de 155

SERVICIOS CLOUD de cliente con SSPP
Las incidencias de servicios CLOUD se envían en una tabla independiente, de acuerdo

con la información (y misma estructura) recibida desde SSPP Cloud:
ENTIDAD
SERVICIO SLA STATUS
CLIENTE
Nombre Cliente o
Nombre Servicio 100% OK
subcliente
Nombre Cliente o
Nombre Servicio 97.88% OK
subcliente
Nombre Cliente o
Nombre Servicio 100% KO
subcliente
Por favor, para cualquier consulta relacionada con los eventos de Comunicaciones
(Datos+Voz), TI (LAN+VCF) reflejados en este informe, contactad con el CEx mediante los
procedimientos habituales.
Para cualquier consulta relacionada con los eventos de Cloud reflejados en este informe,
contactad con CS SSPP mediante los procedimientos habituales.
Saludos.
Nombre Servicio CEx/CGE

Tel +34 000 00 00 00
Email buzón_generico_servicio cex/cge@telefonica.com
NOTAS
- La parte de COM aplica a todas las incidencias activas para cada cliente.
- El criterio que se sigue para que un CEx tenga claro cómo identificar un circuito como crítico
en sistemas es:
- Revisión de estos por parte del GdST y GS, levantando los que consideren críticos de
ese cliente.
- Se puede personalizar al idioma de atención que haya contratado el cliente.
Edición 1.8
Página 135 de 155

- En la columna “ENTIDAD / CLIENTE” cabe la posibilidad de que algunos clientes dispongan de

varios Sub-CIF asociados al mismo CG Lógico, de ahí que pueda haber varias posibilidades de
Nombres.
En el supuesto de que algún cliente no quiera recibir informe “Health-Check” de todos sus
sub-cifs (por ejemplo, por motivos de disgregación de departamentos, etc…), deberá
solicitarlo formalmente (vía email y especificando el motivo) al Comercial, CEx CGE y Gestor
de Servicio; incluyendo por tanto el CEx en esta columna información únicamente de los sub-
cifs que requiera el cliente.
- En la columna “ESTADO” o “STATUS” se deben intentar limitar las posibles opciones de

PENDIENTE a las siguientes:
o Pendiente cambio EDC.

o Pendiente Incidencia Línea.
o Pendiente actuaciones en Red.
o Pendiente de ventana de actuación con clientes.
Edición 1.8
Página 136 de 155

13 ACTIVIDADES DE PROVISIÓN
El CEx/CGE es el máximo responsable para la entrega del servicio gestionado mediante un pedido
comercial LOGOS.
Los pedidos comerciales LOGOS pueden ser de tres tipologías:
- Alta del servicio (Instalación del EDC y/o del circuito).
- Modificación (sobre un EDC y/o circuito ya instalado, adicción de un nuevo elemento como
puede ser una VLAN, modificación de sistemas de routing WAN, etc…).
- Baja del servicio (retirada del EDC y/o baja del circuito).
Para verificar una correcta entrega del servicio intervienen diversas etapas y actividades,
entrelazándose en algunos puntos el ámbito de responsabilidad del CEx/CGE con el ámbito de
responsabilidad de otras figuras, como pueden ser el Gestor de Servicio, OdP o Jefe de Proyecto.
Los aspectos que vamos a relatar a continuación aplican de forma global a todos los servicios de
comunicaciones con pedido LOGOS, aunque siempre habrá que consultar las guías operativas
específicas de cada servicio dado que existen particularidades diferenciales en varios de ellos.
El horario habitual de provisión de los servicios es L-V laborables de 08 a 20:30. Cuando se requiera la
intervención del CEx/CGE fuera del horario habitual se deberá informar al centro vía correo
electrónico con una antelación mínima de 48h laborables (los buzones de correo se pueden consultar
en LOGOS PT) para que el centro confirme su disponibilidad.
En servicios CGE cuyo horario no es 24x7 se debe añadir a lo anterior la limitación del horario de
presencia del CGE, ya que los CEx Estándar o Premium que realizan el FFHH de los CGE no realizarán
actividades relacionadas con la provisión. Si el cliente solicita trabajos de provisión fuera del horario
de presencia del CGE o intervención de un bloque de actividad (fuera de su horario) distinto al de
operación TIC se debe gestionar un pedido comercial que ampare los trabajos necesarios por parte
del CGE para su ejecución. El pedido debe llegar al Coordinador de Gestión responsable del centro,
con una antelación mínima de 48 h laborables.
En instalaciones con necesidad de coordinación de corte el CEx/CGE o el Jefe de Proyecto deberán

agendar el corte desde la Agenda de Indico donde identificarán la disponibilidad de todas las áreas
implicadas, apoyándose en el documento "BTO-PYM-SIS-GUI-47549 AUTONOMÍA EN LA GESTIÓN DE
CORTES" en el supuesto de dudas sobre el horario de algún área.
13.1 A15 - ATENCIÓN A INSTALADORES
Como primer punto de responsabilidad, el CEx/CGE deberá encargarse de la “Recogida de

Datos Técnicos” contactando con el interlocutor válido de cliente identificado en el pedido Logos y/o
el plan de comunicación establecido con su cliente.
Edición 1.8
Página 137 de 155

Básicamente consistirá en obtener los datos de configuración relativos a la parte LAN (IP LAN,
routing estático LAN, DHCP, NAT o similares).
Una vez obtenida esta información, deberá documentarse en el módulo “Recogida Datos
Técnicos” de Gestope para facilitar la generación de la plantilla de configuración final de cliente,
así como para habilitar el acceso SSH al EDC vía “Pasarela Personalizada Empresas –
Gestibercom”.
El segundo punto de responsabilidad CEx/CGE para esta actividad consistirá en la

“Certificación de la Instalación”.
Este apartado consiste en recepcionar la llamada del instalador de I+M desde el domicilio de
cliente y verificar que el EDC está accesible (o confirmar su retirada si así procede) realizando
todas las comprobaciones oportunas especificadas en los procedimientos de provisión (modelo
del EDC, versión de IOS, calidad de parámetros del circuito, etc…).
(*) Para algunos escenarios que no conlleven “Coordinación de Corte” y solamente para los
servicios MacroLAN, Datainternet (incluido LITE), VPNIP y la Facilidad SILAN; esta actividad podrá
realizada de forma autónoma por parte del instalador I + M sin necesidad de llamada al CEx/CGE
(utilizando el aplicativo VUIM).
(**) Quedan exentos de esa particularidad aquellos pedidos donde, aunque se cumpla el punto
anterior existan condicionantes de pruebas específicas con cliente o migraciones que afecten a
escenarios principal / backup.
(***) En el supuesto de que falle la prueba de accesibilidad a través de VUIM, el técnico de I+M
deberá ponerse en contacto con CEx o con el CdS dependiendo de la problemática.
13.2 A16 - COORDINACIÓN DE VENTANAS DE ACTUACIÓN
Esta actividad conlleva 4 bloques diferenciados, estando marcados sobre cada uno de ellos una figura
de responsabilidad distinta.
El objetivo de los bloques será conseguir la coordinación del corte entre todas las áreas implicadas
para poder ejecutar la actividad A15 sin percances. Los cuatro bloques existentes son:
Programación del Corte.

Coordinación del Corte.
Ejecución del Corte.
Soporte ante problemas de Coordinación.
Existirán dos posibles escenarios de partida:

Pedidos Logos con “Jefe de Proyecto y/o OdP Carterizados”.
Pedidos Logos sin “Jefe de Proyecto y/o OdP”.
Edición 1.8
Página 138 de 155

En aquellos casos donde NO exista la figura de “Jefe de Proyecto y/o OdP” la responsabilidad de
programación, Coordinación y Ejecución del Corte recaerá siempre en el CEx/CGE.
Por el contrario, cuando sí exista la figura de “Jefe de Proyecto y/o OdP” la responsabilidad de
Programación y Coordinación del Corte recaerá en dicha figura.
Adjuntamos cuadro resumen de responsabilidades:
Atención
Programación Coordinación Ejecución
Contratada
FlexWAN by Fortinet NOC + JdP JdP JdP NOC
FlexWAN by Fortinet NOC sin JdP CEx CEx NOC
Resto de Servicios/Escenarios CEx + JdP JdP JdP CEx
Resto de Servicios/Escenarios CEx sin JdP CEx CEx CEx
(*) Matizar que quedan exentos de esta actividad por parte de CEx/CGE aquellos pedidos LOGOS
que no tenga una naturaleza comercial, sino que sean proyectos internos de la compañía, por
ejemplo, cambios de asignación de DSLAM ATM a DSLAM IP (siempre y cuando no haya cambio de
EDC). En esos casos, la responsabilidad de la tarea de Programación, Coordinación y Ejecución del
Corte recaerá en el área D&I (Diseño e Implementación).
13.3 A19 - CONFIGURACIÓN Y ACTIVACIÓN DEL SERVICIO
Esta actividad es responsabilidad del CEx/CGE, independientemente de que en fases anteriores haya
habido otra figura responsable (como ocurre a veces en A16).
El objetivo de esta actividad se centra en completar la configuración final del EDC de acuerdo con los
requerimientos específicos de configuración LAN de cliente siempre y cuando no hayan podido ser
documentados previamente en la etapa “Recogida de Datos Técnicos” bien por no disponer de ellos
o bien por no ser un escenario de plantillas soportado por el módulo ReDAT de Gestope.
Igualmente, aplicará esta actividad para pulir la configuración definitiva en aquellos escenarios NO
estándar donde exista un proyecto técnico que detalle configuraciones especiales.
Cuando se requiera un Proyecto Técnico (PT) para la ejecución de alguna actividad, se deberá
solicitar al Ingeniero de Clientes (IdC) y al Gestor de Servicio (GS) correspondiente, por correo y
teléfono. En caso de no obtener respuesta en el plazo de 2 horas, de deberá incidentar el pedido de
Edición 1.8
Página 139 de 155

acuerdo con lo especificado en el documento “BTO-PYM-SOP-GUI-60233 Catalogo Incidencias

LOGOS".
13.3.1 PROVISIÓN RPV INTERNACIONAL
Provisión internacional seguirá centralizando la actividad haciendo la entrega al CEx/CGE

correspondiente (según la asignación de la tabla RCC de LOGOS-PT), facilitando una plantilla con los
datos del pedido. El CEx/CGE será el encargado de realizar la Puesta en Marcha y las pruebas finales
con cliente para validar la instalación en un plazo máximo de 7 días desde la entrega. Esta actividad
de provisión se debe registrar en GDIA, y los elementos de internacional se deben registrar
manualmente en LOGOS-PT.
La operativa completa de la provisión de este servicio está en el documento BTO-PYM-PYS-GUI-5861

GUI_PROVISION RPV INTERNACIONAL.
13.4 A20 - VALIDACIÓN DEL SERVICIO Y TESTEO
Una vez configurado el EDC y realizadas las pruebas del servicio, es necesario contactar con cliente
para informarle de la disponibilidad del servicio, informarle de los datos de configuración, confirmar
con él dichos datos, e invitarle a la realización de sus pruebas del servicio (tanto a nivel local de la
propia sede como entre sedes si así procede).
La vía de contacto debe ser por teléfono, a no ser que se hayan establecido otras vías previo acuerdo
con cliente.
En este punto, es posible que el cliente no quiera o pueda realizar pruebas de servicio. En ese
supuesto, deberá finalizarse el pedido de provisión especificando en el formulario RASER la
problemática para no poder realizar dichas pruebas e informar de las fechas acordadas con cliente
para realizarlas.
Una vez validamos el paso a operación del servicio, debemos asegurarnos de que los servicios,
equipos, circuitos, etc, vuelquen de los sistemas de provisión a los sistemas de inventario de planta,
para que se creen, actualicen, o se eliminen en caso de baja. Parte de esta tarea la realizan los
automatismos entre sistemas y otras las debemos hacer según lo indicado en la actividad “A22-
Control de Inventario” y las guías de la BTO relacionadas.
Además, nos debemos asegurar de que los equipos y circuitos se creen, actualicen, o eliminen del
sistema de inventario de la planta (LOGOS-PT, CIBERUN), según corresponda al movimiento de
provisión, junto con la activación o desactivación de la monitorización en WOCU, y el automatismo
de diagnóstico y apertura de incidencias de ASTRO. Para más detalle ver apartado 5.1
Parametrizaciones WOCU.
Edición 1.8
Página 140 de 155

14 DEROGACIONES Y EFECTIVIDAD
Con la publicación de este documento, que entrará en vigor el día 15 de febrero de 2023, queda
derogada la versión anterior de esta guía.
15 APROBACIÓN
Elaborado por:
Procesos TSO
Revisado por:
Mónica Alcalá Lorenzo
Marta Peligros Zarza
David Soriano Gil
Aprobado por:
Susana Chamorro Frías
Jefatura de Calidad, Procesos y Sistemas TSO
Edición 1.8
Página 141 de 155

ANEXO 1: DEFINICIONES
Gestión de eventos: Asegurar que los Elementos de Configuración (CI) y los servicios sean
monitoreados constantemente, así como descartar y categorizar Eventos antes de decidir qué
acciones son las adecuadas. Clasificar aquellos eventos que se pueden obviar, y asignar categorías a
los que son significativos. Interpretar el significado de un Evento y elegir una respuesta adecuada.
Verificar que los Eventos hayan sido manejados adecuadamente y si se pueden cerrar. Este proceso
también sirve para asegurar que los registros de eventos sean analizados de manera que se
identifiquen tendencias y patrones que puedan sugerir medidas correctivas necesarias.
Gestión del incidente: El objetivo principal del manejo de incidentes es devolver el servicio de TI a los
usuarios lo antes posible, con alguna solución temporal de ser necesaria. Proveer y mantener las
herramientas, los procesos, las destrezas y las reglas para un manejo de incidentes efectivo y
eficiente. Registrar y asignar prioridades a los incidentes con la diligencia adecuada, de manera que
se faciliten soluciones efectivas e inmediatas. Monitorizar constantemente el estatus del
procesamiento de Incidentes pendientes, para que inmediatamente se tomen medidas que
contrarresten efectos adversos en caso de que peligren los niveles de servicio. Someter el Registro de
Incidente al control de calidad final antes de que se dé un cierre. Informar a los usuarios de fallos en
el servicio tan pronto como se conozcan.
Gestión de problemas: Prevenir los incidentes y minimizar el impacto de aquellos que no pueden
prevenirse. La Gestión Proactiva de Problemas analiza los Registros de Incidentes y utiliza datos de
otros procesos de Gestión del Servicio de TI para identificar tendencias o problemas significativos.
Identificar la raíz de los problemas e iniciar las soluciones más adecuadas y económicas. De ser
posible, se proveerán soluciones temporales. Llevar un registro detallado de problemas y errores
conocidos. Revisar la solución de los problemas para prevenir su recurrencia y aprender lecciones
para el futuro.
Gestión de peticiones: Es responsable de gestionar las peticiones de usuarios y clientes que

habitualmente requieren pequeños cambios en la prestación del servicio. Son en realidad pequeños
cambios de bajo riesgo, bajo coste, y que ocurren frecuentemente, también puede ser una solicitud
de información o peticiones de acceso a servicios.
Gestión de accesos: Otorgar el derecho a un servicio a usuarios autorizados, mientras se previene el

acceso de usuarios no autorizados. Los procesos de Gestión del Acceso ponen en práctica las políticas
definidas por la Gestión de Seguridad de TI. La Gestión del Acceso también es conocida como Gestión
de Derechos o Gestión de Identidad. Asegurar que el Catálogo de Roles de Usuarios y los Perfiles de
Acceso de Usuarios sean apropiados para los servicios ofrecidos a los clientes, y prevenir una
acumulación indeseada de derechos de acceso. Procesar pedidos para agregar, cambiar o revocar
derechos de acceso, y asegurar que sólo los usuarios autorizados tengan derecho a usar
determinados servicios.
Gestión del cambio: Asegura que se usen procedimientos y métodos estandarizados para el manejo
de todos los Cambios y que son evaluados, aprobados, implementados y revisados de manera
controlada, asegurando en todo momento la calidad y continuidad del servicio.
Edición 1.8
Página 142 de 155

Evaluación del cambio: Proporcionar un medio uniforme y estandarizado de determinar el resultado

de un cambio de servicio en el contexto de los probables impactos en el negocio, los servicios
existentes y propuestos, y la infraestructura de TI. El resultado real de un cambio se evalúa en
función de su resultado previsto. Los riesgos y problemas relacionados con el cambio son
identificados y gestionados.
Gestión de la configuración y activos del servicio: Conservar información acerca de los Elementos de
Configuración (CI) requeridos en la prestación de un servicio de TI, incluyendo las relaciones entre los
mismos. Definir y actualizar la estructura del CMS de manera que contenga la información
relacionada con los Elementos de Configuración (CI), incluyendo sus atributos y relaciones. Llevar a
cabo controles periódicos, asegurando que la información contenida en el CMS sea una
representación exacta de los Elementos de Configuración (CI) instalados en el entorno de producción
real.
A1 Atención al Usuario: Atención al usuario final del servicio ante incidencias, solicitudes,
reclamaciones, provisiones y escalados, y asesoramiento sobre el uso de servicios.
A3 Monitorización de eventos de la explotación: Supervisión proactiva de los servicios; filtrado y

categorización de eventos con el objetivo de realizar las acciones adecuadas según procedimiento en
cada caso.
A4 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones – Registro:
Registro de incidencias, peticiones, consultas y reclamaciones.
A5 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones - Diagnóstico de
incidencias: Investigación de las causas de las incidencias y obtención de un diagnóstico.
A6 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones – Transferencia:
Encaminamiento al grupo correspondiente por procedimiento de incidencias, peticiones, consultas y
reclamaciones.
A7 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones - Información:
Información del estado de las incidencias, consultas, peticiones y reclamaciones por los medios
habilitados a tal efecto.
A8 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones - Seguimiento y
Escalado: Seguimiento extremo a extremo de las incidencias, peticiones, consultas y reclamaciones
asegurando que se cumplen los SLAs asociados al servicio y escalado de las desviaciones detectadas
para su corrección.
A9 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones - Resolución:
Realización de las acciones necesarias según procedimiento para la resolución de incidencias,
peticiones, consultas y reclamaciones.
Edición 1.8
Página 143 de 155

A10 Gestión del ciclo de vida de las incidencias, peticiones, consultas y reclamaciones - Confirmación
de cierre: Confirmación de resolución de la incidencia mediante las pruebas y acciones necesarias y
cierre de la misma.
A11 Gestión de problemas: Análisis del histórico de incidentes y evaluación de la información

disponible, incluyendo tendencias y otros patrones, con el objetivo de solucionar incidencias
reiteradas o escalar y solucionar problemas que afectan a volúmenes agregados de incidencias.
A12 Ejecución de operaciones de mantenimiento preventivo y correctivo: Ejecución de tareas

rutinarias con acción preventiva y correctiva sobre componentes de infraestructura y aplicaciones
relacionadas con los servicios: realización de pruebas de backup, revisión de configuraciones,
ejecución de roll-outs de SW, etc. Gestión y seguimiento del servicio de mantenimiento de equipos.
A13 Cambios de configuración: Gestión de la configuración en elementos y aplicaciones del servicio

ante modificaciones.
A22 Control de inventario: Creación, actualización y control de información de la CMDB del servicio.
A23 Inventariado de configuraciones (Asset Management): Obtención y actualización de la

información de configuraciones de elementos y servicio requeridas para su correcta prestación.
A24 Reporting: Elaboración de información de reporting sobre los servicios incluyendo procesos de
provisión, mantenimiento, pedidos, incidencias singulares, niveles de servicio, facturación e
inventario.
A15 Atención a instaladores: Atención a los instaladores de elementos relacionados con el servicio
proporcionando la información necesaria para ejecutar las instalaciones.
A16 Coordinación de ventanas de actuación: Coordinación y seguimiento de cortes de servicio y

gestión de ventanas de actuación.
A19 Configuración y activación de servicio: Configuración de elementos de servicio o puesta en

marcha.
A20 Validación del servicio y testeo: Validación de cumplimiento de requisitos y expectativas de

Cliente en los despliegues de servicios realizados y realización de pruebas finales con cliente.
Gestión del Servicio: es un conjunto de capacidades organizativas que añaden valor a los activos del
cliente en forma de servicios. Estas capacidades toman la forma de Procesos y Funciones para
gestionar un servicio a través de un Ciclo de Vida. La implementación y gestión de servicios de TI de
calidad que satisfagan las necesidades del negocio. Valor es el núcleo del concepto del Servicio y se
compone de Utilidad y Garantía.
Proceso: conjunto de actividades interrelacionadas orientadas a cumplir un objetivo específico.
Edición 1.8
Página 144 de 155

Procedimiento: Son los métodos de ejecución que se realizan para conseguir que el proceso se
materialice.
Actividad: serie de acciones que se ejecutan con el fin de alcanzar los objetivos planteados. Las
actividades están subordinadas a un Procedimiento.
Tarea: ejecución orientada a lo instantáneo. Se caracteriza por tener un tiempo limitado y se hace
con miras a cumplir con una actividad.
Eventos: eventos suelen ser alarmas en principio sin impacto en el servicio, y que si lo pueden
producir deben mantenerse en observación.
Incidentes: son alarmas que afectan al servicio prestado a los clientes y usuarios, como por ejemplo
incomunicación, degradación del servicio, etc.
Problemas: son incidentes repetitivos y complejos que deben estudiarse en profundidad para
identificar tendencias o problemas significativos, aportando soluciones temporales y/o definitivas.
CI: Configuration Item, o elementos de configuración que hacen parte de una agrupación,
componentes de una infraestructura.
EDC: Equipo en domicilio de cliente.
CMDB: Configuration Management Data Base, o base de datos de la gestión de la configuración que
contiene detalles relevantes de cada CI (ítem/elemento de configuración).
Incidencias repetidas: una incidencia se considera repetida si ha ocurrido otra incidencia sobre el
mismo circuito en un plazo menor de 30 días.
Incidencias locales: son las incidencias que debido a que no afectan al servicio o a causas de cliente,
no se pueden tratar con normalidad, como pueden ser en oficinas con horario reducido, si el cliente
demora la atención de la avería en un tiempo superior a 48 horas laborales (excluido el fin de
semana).
Incidencias anuladas: son las incidencias que se anulan por tener errores en su registro, como
incidencias duplicadas, con datos erróneos o mal abiertas, o relacionadas con bajas.
Incidencias masivas: son las que afectan a varios circuitos o equipos en una misma zona geográfica
en un mismo instante, y que comparten algún elemento común de la red.
Incidencias: Fallos o mal funcionamiento de elementos, sistemas, o servicios.
Peticiones: Solicitudes realizadas por el cliente, generalmente asociadas a modificaciones no

facturables.
Edición 1.8
Página 145 de 155

Consultas y reclamaciones: Solicitudes de información, reiteración, o escalación realizadas por el

cliente, sobre tickets ya abiertos.
PVEE: Postventa Empresas
Edición 1.8
Página 146 de 155

ANEXO 2: PLAN DE COMUNICACION A CLIENTE
El plan de comunicación establece y describe los contactos mínimos que debe realizar el CEx/CGE con el cliente durante el ciclo de vida de las
incidencias.
Para cada incidencia, se debe identificar al interlocutor de cliente más adecuado según el modelo de comunicación establecido con el Cliente, que será la
persona a la que se mantendrá informada durante la vida de la incidencia y debe tener la trazabilidad total de la evolución de la misma. Los datos de
contacto de dicho interlocutor deben quedar reflejados en la información global del ticket de la herramienta de ticketing. La persona de contacto y sus
datos (teléfono, correo electrónico, etc.) solo puede ser personal del cliente, en ningún caso pueden ser de Telefónica (CEx/CGE, GdST, GS, Comercial).
El rechazo de cliente a alguna de las vías de comunicación debe ser solicitada expresamente por la persona de contacto registrada en el ticket, desmarcar
el check de la vía rechazada, y documentar su justificación en un comentario.
En la siguiente imagen se adjunta un resumen gráfico del plan de comunicación:

Edición 1.8
NIVEL DE CONFIDENCIALIDAD: RESTRINGIDO. Queda prohibida cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio, de este documento sin
el previo consentimiento expreso y por escrito de Telefónica Soluciones de Outsourcing S.A.U.
Página 148 de 155

A continuación se detallan los contactos mínimos del plan de comunicación que deben ejecutar los
CEx/CGEs.
Premisas generales:
El CEx no es responsable de la comunicación de aquellas incidencias que están asignadas al
automatismo.
La vía telefónica se utilizará solo dentro del horario de cliente.
Un contacto telefónico ilocalizable, es decir, no se ha podido contactar con el cliente por lo

tanto no se ha realizado la comunicación, debe ser realizado siempre por otra vía de comunicación.
Frecuencia, vía y registro del Plan de Comunicación:

Primera hora de vida de la incidencia: En todas las incidencias es obligatorio realizar 1
contacto vía mail o sms. En este contacto se informará al cliente de la apertura de la incidencia y se
deberán incluir los datos que permitan al cliente identificar la sede/equipo/circuito/servicio afectado,
el número del ticket registrado y cómo puede contactar con Telefónica para conocer el estado de la
avería o facilitar información adicional sobre la misma.
Este contacto se registrará como contacto de primer diagnóstico.
En las dos primeras horas de vida de la incidencia dentro del horario de la sede: En todas
aquellas incidencias que sean transferidas a otras áreas será obligatorio realizar un contacto
telefónico con el objetivo de hacer todas las pruebas necesarias que permitan realizar un diagnóstico
concluyente de la avería y confirmen la necesidad de transferir la incidencia a otra área para su
resolución.
En el caso de que el contacto telefónico sea ilocalizable, además de ser necesario realizarlo
por otra vía, el CEx deberá asegurarse de realizar un contacto telefónico con éxito antes de
realizar la transferencia a un tercero. Esto es, hasta que no haga las verificaciones necesarias
con cliente para confirmar el diagnóstico no se deberá realizar la transferencia a otra área.
En los casos en los que la incidencia se detecte dentro del horario de la sede y este contacto
se haga a la vez que el anterior (vía mail o sms), se registrará un único contacto de primer
diagnóstico en el que se incluirán todas las vías de comunicación utilizadas
(mail/sms/teléfono). En el resto de los casos este contacto se registrará como contacto de
evolución.
Siempre que haya nueva información: Siempre que exista nueva información sobre la
incidencia será necesario informar al cliente. El CEx debe asegurarse de recopilar la información
necesaria para transmitir al cliente información actualizada y de calidad sobre el estado de su avería.
Estos contactos se registrarán como contactos de evolución.
Como mínimo: en incomunicaciones, será necesario realizar como mínimo 2 contactos

diarios, uno por la mañana (antes de las 12) y otro por la tarde.
En el resto de las incidencias será necesario como mínimo un contacto diario hasta el cierre
de la incidencia.
Una vez resuelta la incidencia: Se deberá confirmar con el cliente que la incidencia ha
quedado resuelta y puede cerrarse. Para ello:
Si la incidencia se ha resuelto dentro del horario de la sede : Deberá realizarse el contacto vía
telefónica.
Si la incidencia se ha resuelto fuera de horario : Se enviará un mail o sms al cliente

informando de la resolución de la avería y se realizará un contacto telefónico cuando la sede abra
para confirmar la resolución con el cliente.
Si el contacto telefónico es ilocalizable : Se realizará el contacto vía mail o sms y se intentará

al menos otro contacto telefónico dentro de horario de la sede en otro día diferente. Esto es, se
deben intentar al menos dos contactos telefónicos en horario de cliente y en días diferentes antes de
cerrar la incidencia.
Si el cliente solicita mantener la incidencia en observación o lo decide el CEx será necesario

realizar un contacto diario mientras la incidencia esté abierta y un contacto de cierre antes de
proceder al cierre definitivo de la incidencia.
Estos contactos se registrarán como:
Mantener en observación:
Si la incidencia se resuelve fuera de horario o no se consigue localizar al cliente y se le

informa de la resolución de la avería vía mail o sms.
Si al comunicar al cliente la resolución de la avería nos solicita que la mantengamos en

observación o si el CEx decide mantener la incidencia en observación y contacta con el cliente para
informar de ello.
Cierre: Se registrará como contacto de cierre:
El contacto telefónico en el que se confirma con el cliente el cierre de la incidencia.
El mail en el que se informa al cliente del cierre de la incidencia tras obtener la confirmación
del cliente al cierre de la incidencia.
Si tras dos contactos telefónicos en días diferentes dentro del horario de la sede no se ha
podido contactar con el cliente, se enviará un mail al cliente informando del cierre de la avería. Este
contacto también deberá registrarse como contacto de cierre.
Todas las incidencias deben tener un contacto de cierre.
NOTAS:
Edición 1.8
Página 150 de 155

- Para los clientes en los que se ha aprobado la excepción “Exclusión Vías de comunicación”
para realizar los contactos con el cliente a través de la herramienta de ticketing de cliente, se
podrán realizar por la vía “otros sistemas de tickets” los contactos del plan de comunicación
cuya vía sea email o sms. En estos casos deberá indicarse en GDIA el id del ticket abierto en la
herramienta de cliente.
Los contactos que deben realizarse vía teléfono no pueden ser sustituidos por la vía de
comunicación “otros sistemas de tickets”.
- Para las incidencias gestionadas en contingencia, ante la caída de GDIA:
SMS: Esta vía de comunicación se descarta al no disponer de la posibilidad de envío de sms.
Mail: Envío de correos.

En los CEx Premium, CEx Premium+ y CGE en los que para los servicios integrados en GDIA se
envían los correos desde el buzón del centro, se mantiene la misma operativa enviando los correos
de acuerdo con el Plan de Comunicación desde el buzón del centro.
En los CEx Estándar y CEx Avanzado en los que para los servicios integrados en GDIA se
envían los correos desde el buzón genérico “TE_CENTROS_GESTION_EMPRESAS”, no se enviarán
correos desde el buzón del centro, sustituyendo todas las comunicaciones obligatorias por llamada
telefónica.
Edición 1.8
Página 151 de 155

ANEXO 3: HISTÓRICO DE REVISIONES
Edición Fecha Observaciones - Modificaciones
1.0 01/12/2020 Creación del documento.
Operativa de transferencia de llamada en caliente de cliente desde el CGC / 1002 a

los CEx (Estándar) y CEx Avanzado.
1.1 31/03/2021
Actualización de la tripleta de cierres.
Actualización de la actividad de control de inventario.
Actualización de la actividad de operaciones de mantenimiento preventivo y

correctivo.
Actualización por migración de ETICA a LOGOS-PT.

1.2 07/07/2021
Aclaración del alcance de la actividad de diagnóstico de incidencias.
Operativa de gestión reactiva ante incidencias cerradas no resueltas.
Inclusión de los apartados 4.1 “PARAMETRIZACIONES WOCU” y 4.2 “CUADRO

RESUMEN PARAMETRIZACIONES WOCU”.
Se renombran las facilidades de los Gateway NGN en la tabla de registro del apartado
5.1.
Inclusión del formato del asunto de los mails de seguimiento / escalado en el

apartado 5.5.1 “ASEGURAMIENTO DEL PROCESO DE RESOLUCIÓN DE INCIDENCIAS”.
1.3 31/08/2021
En el apartado 5.6.1 se incluye:
Datos: cierre para incidencias de Backup cuando el cliente declina que el CEx
realice las pruebas.
Voz: cierre para incidencias masivas en los servicios de voz
En el apartado 7 se incluye el registro de las incidencias de pruebas de backup

cuando el cliente declina su realización.
1.4 29/12/2021 Apartado 3 A1 - ATENCIÓN AL USUARIO: Aclaración de la aplicación en los servicios

internacionales de la transferencia de llamada en caliente desde el CGC al CEx.
Apartado 5.1 A4 – REGISTRO: Actualización del listado de síntomas de los servicios a

utilizar en SAC VANTIVE/GDIA. Se incluye comentario sobre la realización y registro
del contacto de apertura según lo indicado en el Anexo 3.
Apartados 5.2 A5 - DIAGNÓSTICO DE INCIDENCIAS, 5.4 A7 – INFORMACIÓN, y 5.6 A9 -

Edición 1.8
Página 152 de 155

RESOLUCIÓN: Se elimina el detalle de los contactos de primer diagnóstico, evolución,

y cierre respectivamente, y se incluye comentario sobre la realización y registro de
estos contactos según lo indicado en el Anexo 3.
Apartado 5.6.1 TABLAS DE RESOLUCIÓN/CIERRE POR SERVICIO: Se actualizan y

agregan los cierres a utilizar en la realización de las pruebas de backup en los
servicios Ibercom IP y Corporate IP Alojado.
Apartado 5.7 A10 - CONFIRMACIÓN DE CIERRE: Se incluye comentario sobre la

realización y registro del contacto de cierre según lo indicado en el Anexo 3.
Apartado 7 A12 - EJECUCIÓN DE OPERACIONES DE MANTENIMIENTO PREVENTIVO Y

CORRECTIVO: Aclaración del proceso de “Carga Certificados WIFI para iAPs”.
Anexo 3: Inclusión del Anexo 3 con la actualización del del plan de comunicación a
cliente.
1.5 17/05/2022 Apartado 3:

Se elimina el servicio Movistar Fusión Empresas Premium.
Se actualiza debido a los cambios en las tareas de Agenda que recibe el CEx
en GDIA.
Se incluye el apartado 4.1.1 SISTEMA DE CRÉDITOS COMPARTIDOS.
Apartados 4.1, 4.2 y 5.1: Ampliación de detalle al respecto de requerimientos

necesarios para una correcta detección de evento + apertura proactiva de tickets.
Inclusión de información referente al agente ASTRO.
Apartado 5.1:
Se detalla en qué casos los DoP, GS, GTA, GdX y CdS Ibercom Provisión
pueden solicitar actividad a los CEx, cómo deben relacionarse y cómo debe
registrarse la actividad.
Se actualiza la definición del síntoma “Fallo en acceso a monitorización” al
aplicar para cualquier fallo en la gestión/monitorización.
Se incluyen los síntomas “revisión de tareas y configuración” y “soporte
primer uso” para los servicios Ibercom Ip, CoIp Alojado e Ibercom Ip en red.
Se añaden dos nuevos tipos de incidencias que deben registrarse con Fase
de servicio Provisión.
Se incluyen los síntomas a utilizar en los GW NGN.
Se actualizan las tareas de Agenda que recibe el CEx en GDIA, y se actualizan
las tablas de vías de entrada y recepción.
Apartado 5.1.2: Se elimina la “Solicitud de RFO (Informes) en RPV Internacional” de
los casos de incidencias locales que no afectan al servicio.
Apartados 5.1.3, 5.1.4, 5.1.5, 5.1.6: Se corrige la numeración de estos apartados por
la correcta.
Edición 1.8
Página 153 de 155

Apartado 5.4: Se actualiza la información referente al interlocutor de cliente.
Apartado 5.6.1: Tabla de resolución/cierre por servicio:
Servicios de Datos: Actualizadas las opciones que aplican al cierre Telefónica

– EDC-Router – Configuración desde el centro de gestión.
Servicios de Voz: Se incluyen los cierres: Telefónica – EDC-Router – Cambios
de configuración y Telefónica – EDC-Router –
Apartado 9.1.1: Lo descrito en este apartado pasa a ser obligatorio, antes eran
recomendaciones.
Anexo 3: Se aclara como deben registrarse los contactos en la herramienta de

ticketing una vez que la incidencia ha quedado resuelta.
1.6 21/07/2022 Se suprimen todas las referencias al agente OMEGA sustituyéndolo por ASTRO en la
detección de eventos de monitorización para apertura proactiva de tickets.
Apartado 3: Se agrega este nuevo apartado “Introducción”. Se incluye referencia al

sistema ATEx.
Apartados 5.1 y 5.2: Se incluye la parametrización WOCU de los Gateway NGN, así
como aclarar qué tipo de peticiones pueden registrarse y por parte de quien en
https://ctic.tesa/
Apartado 6.1:
- Se modifica el registro de las incidencias de los servicios Centrex IP y Gateway NGN.
- Se incluye el registro de las incidencias del servicio FlexWAN.
- Se detalla en qué casos el instalador del servicio Centrex puede contactar con el
CEx/CGE y cómo debe registrarse esa actividad.
Apartado 6.1.3: Se aclara el redactado de este apartado.
Apartado 6.3: Se aclaran las acciones necesarias para realizar la transferencia por
Sirio.
Apartado 6.6: Se aclaran las acciones a realizar ante el franqueo de un Sirio.
Apartado 8: Se actualiza el diagnóstico asociado al mantenimiento preventivo.
Apartado 10.1: Se actualizan acciones a realizar sobre campos LOGOS PT de EDCs
ante posibles apagados vacacionales o bajas no tramitadas comercialmente (campo
Plataforma_Omega).
Apartado 13: Se corrige el horario habitual de provisión y se elimina la necesidad de
pedido SGC en centros 24x7 para provisiones fuera del horario habitual.
Anexo 1: Se elimina y parte de su contenido se incorpora al nuevo Apartado 3.
Anexo 2: Antes Anexo 3, se elimina la referencia a incidencias críticas y se añade
excepción de otros sistemas de tickets.
Edición 1.8
Página 154 de 155

Actualizadas las referencias a la nueva modalidad “Datainternet LITE”, dependiente

del servicio DATAINTERNET.
Apartado 4:
- Se informan los idiomas de atención de CEx en la transferencia en caliente.
Apartado 6.1: Se actualizan las tablas con las nuevas vías de entrada y recepción de la
actividad.
Apartado 6.1.2: Se aclara el procedimiento y casos de las incidencias locales.
Apartado 6.1.3: Se agrega el caso de las incidencias mal abiertas por el Service Desk.
Apartado 6.1.4: Se actualiza y aclara el funcionamiento de GDIA y actuación ante
1.7 29/11/2022 incidencias masivas.
Apartado 6.2.2: Se elimina este apartado al ya estar su contenido en la guía del
servicio RPV Internacional y en la de GDIA.
Apartado 6.6.1: Se agrega el cierre para incidencias en las que el cliente ha demorado
la atención en un tiempo superior a 48 horas, y que tras este período la incidencia no
se ha resuelto o el diagnóstico inicial es erróneo.
Apartado 8: Se agrega la forma de registro en GDIA de las actualizaciones de
software.
Apartado 10.1: Se actualiza la forma de realizar los cambios en la planta de LOGOS
PT.
Anexo 2: Se actualiza el resumen gráfico del plan de comunicación.
Edición 1.8
Página 155 de 155

BTO-PYM-GES-GUI-45429 Guia Operativa Servicios de Conectividad en CEx y CGE v1.8

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

BTO-PYM-GES-GUI-45429 Guia Operativa Servicios de Conectividad en CEx y CGE v1.8

Cargado por

Copyright:

Formatos disponibles

Febrero 2023

TELEFÓNICA SOLUCIONES DE OUTSOURCING

GUÍA OPERATIVA SERVICIOS CONECTIVIDAD EN

Edición Fecha Observaciones - Modificaciones

Se sustituye el apartado Ediciones y Revisiones por los apartados Novedades e Histórico de

En los anexos se encuentra disponible el HISTÓRICO DE REVISIONES.

- Dirección Postventa Empresas.

Este procedimiento es de obligado cumplimiento en los servicios de Telefónica:

- CEx (Gestión estándar)

Esta información debe complementarse con las siguientes fuentes de información:

Personal de proveedor: a definir por el proveedor.

- Los manuales de los sistemas de gestión integrados, pudiendo consultarse su ubicación en

Personal de TSO y Tempotel: Portal de gestión / Gestión catálogo / Mapa de sistemas.

Personal de proveedor: a definir por el proveedor.

- El Manual de marketing CEx/CGE ubicado en la Biblioteca Técnica Operativa (BTO).

- Los procedimientos complementarios e información específica existente en algunos

A continuación, se muestran los procesos contenidos en este documento:

OPERATIVA DE ATENCIÓN Y REGISTRO EN CEX Y CEX AVAZANDO POR TRANSFERENCIA DE

- Incidencias, peticiones (MNF), y consultas de servicios de DATOS y VOZ integrados en CEx y

Acceso Primario Virtual (APV)

- Incidencias, peticiones (MNF), y consultas de los servicios TI de LAN y Videoconferencia

Necesidad de información (consulta) de cliente sobre un ticket ya existente.

Necesidad de escalado de cliente sobre un ticket ya existente.

La transferencia de llamada CGC / 1002 a CEx se realiza siempre (sin excepción).

Implica actividad de Atención en caliente con cliente desde CEx.

Implica el Registro desde CEx de un ticket como actividad de Operación.

Devolver la llamada al CGC / 1002 (transferencia al 1489 o al 1002).

Confirmar si en LOGOS PT aparece correctamente el CEx asociado al cliente. Corregirlo si

Registrar nuevo ticket en GDIA o REMEDY TI.

Para incidencias o modificaciones no facturables de servicios de DATOS y VOZ, registrará

Averías de servicios de DATOS y VOZ

En GDIA -> Fase = “Explotación” y Vía = “Teléfono”

Modificación no facturable de servicios de DATOS y VOZ

En GDIA -> Fase = “Provisión”, Vía = “Teléfono” y Síntoma = “Modificación No Facturable”

Dicho ticket se asignará al grupo de Remedy correspondiente del CEx:

Para clientes de CEx AVANZADO

Para clientes de CEx en modalidad ESTÁNDAR

“N1_LAN_CEX xx” ESTANDAR

“N1_VCF_CEX xx” ESTANDAR

Necesidad de información de cliente sobre un ticket ya existente:

Devolver la llamada al CGC / 1002 (transferencia al 1489 o al 1002).

Confirmar si en LOGOS PT aparece correctamente el CEx asociado al cliente. Corregirlo si

Necesidad de escalado de cliente sobre un ticket ya existente:

La transferencia de llamada CGC / 1002 a CEx se realiza siempre (sin excepción).

Si es ticket GDIA, además de la transferencia al CEx, se realizarán dos acciones adicionales:

CGC realizará su operativa habitual de escalado:

Clientes Carterizados: envío de mail a Gestor de Servicio.

Devolver la llamada al CGC / 1002 (transferencia al 1489 o al 1002).

Confirmar si en LOGOS PT aparece correctamente el CEx asociado al cliente. Corregirlo si

Posteriormente, gestionará el escalado, asegurándose siempre de que, si es ticket GIDA, se ha

Actividad en CGC / 1002: Atención + Transferencia de llamada de cliente a CEx:

Recepción de llamada del cliente en CGC / 1002.

Árbol de decisión del Asesor del CGC / Agente del 1002

Determinar si el problema del cliente es técnico sobre uno de estos casos:

Nueva avería / Nueva petición (Modificación No Facturable)

Información / Seguimiento / Consulta / Asesoramiento sobre ticket abierto

Escalado sobre ticket abierto

Determinar el servicio por el que llama el cliente:

CGC y 1002: Servicio DATOS y VOZ (GDIA)

Sólo CGC: Servicio TI LAN / VCF (REMEDY TI)

Asesor Personal (CGC) o Agente (1002) transfiere llamada en caliente a CEx

El Asesor Personal del CGC hace uso de la botonera 40.

El Agente (1002) hace uso de dicha opción en su menú desplegable.