La Composición fotográfica. Emplazamientos, encuadres y planos.
PLIEGO DE BASES TECNICAS PARA LA CONTRATACION DE …emplazamientos o centros de comunicaciones en...
66
1 de 66 Bizkaiko Teknologi Parkea, 101 • 48170 Zamudio – Bizkaia Tel: 944 03 23 00 • Fax: 944 03 23 01 www.itelazpi.net • [email protected] N.I.F.: A-95282216 Registro Mercantil de Bizkaia, Hoja BI-38047, Folio 102, T 4347 , Inscripción I. – Sociedad Unipersonal I.F.Z.: A-95282216 Bizkaiko Merkataritza Erregistroa, BI-38047 O.a, 102 Oh. a, T 4347 , I. Idazp.a – Persona Bakarreko Baltzua PLIEGO DE BASES TECNICAS PARA LA CONTRATACION DE LA “APLICACIÓN INFORMATICA DE INVENTARIO Y MANTENIMIENTO DE RED DE ITELAZPI, S.A.” Expte.: 008.ST.2014
Transcript of PLIEGO DE BASES TECNICAS PARA LA CONTRATACION DE …emplazamientos o centros de comunicaciones en...
1 de 66
Bizkaiko Teknologi Parkea, 101 • 48170 Zamudio – Bizkaia
Tel: 944 03 23 00 • Fax: 944 03 23 01
www.itelazpi.net • [email protected]
N.I
.F.:
A-9
5282
216
Reg
istr
o M
erca
ntil
de B
izka
ia, H
oja
BI-3
8047
, Fol
io 1
02, T
434
7 , I
nscr
ipci
ón I
. – S
ocie
dad
Uni
pers
onal
I.
F.Z.
: A-
9528
2216
Biz
kaik
o M
erka
tarit
za E
rreg
istr
oa, BI
-380
47 O
.a, 10
2 O
h. a
, T
4347
, I.
Ida
zp.a
– P
erso
na B
akar
reko
Bal
tzua
PLIEGO DE BASES TECNICAS PARA LA CONTRATACION DE LA “APLICACIÓN INFORMATICA
DE INVENTARIO Y MANTENIMIENTO DE RED DE ITELAZPI, S.A.”
Expte.: 008.ST.2014
2 de 66
ÍNDICE
1. OBJETO. ....................................................................................................................... 4
1.1. Antecedentes. ....................................................................................................................... 4
1.2. Alcance del contrato. ............................................................................................................. 5
2. DESCRIPCION DE LA RED DE ITELAZPI. ..................................................................... 7
2.1. Centros de Comunicaciones. Servicio de albergue. ................................................................... 7
2.2. Centros de Comunicaciones. Subsistema de energía. ................................................................ 9
2.3. Subsistema de transporte..................................................................................................... 10
2.4. Subsistema de difusión. ....................................................................................................... 11
2.5. Subsistema de WiMAX. ........................................................................................................ 11
2.6. Subsistema de TETRA. ......................................................................................................... 12
2.7. Subsistema de sistemas de información. ................................................................................ 13
2.8. Subsistema de Infraestructuras de centro. ............................................................................. 13
2.9. Subsistema de Infraestructuras de fibra óptica. ...................................................................... 13
2.10. Resumen de Activos. ........................................................................................................... 14
3. DESCRIPCION DE LOS SISTEMAS DE OPERACION DE LA RED DE ITELAZPI. ........... 16
3.1. Sistemas de gestión específicos por tecnología. ...................................................................... 16
3.2. Sistema Netcool de consolidación de alarmas. ........................................................................ 17
3.3. Aplicación Service Manager de gestión de incidencias. ............................................................ 19
3.4. Software de gestión empresarial ERP. ................................................................................... 24
3.5. Tablas y bases de datos ofimáticas. ...................................................................................... 24
4. APLICACIÓN DE INVENTARIO. .................................................................................. 26
4.1. Definición y modelado de activos. ......................................................................................... 26
4.2. Funcionalidades de Gestión de Inventario de Red. .................................................................. 29
4.3. Funcionalidades de Gestión Documental. ............................................................................... 31
4.4. Funcionalidades de reporting/informes .................................................................................. 33
4.5. Integración con ficheros y bases de datos ofimáticas de Itelazpi .............................................. 33
4.6. Integración con otras aplicaciones de Itelazpi ........................................................................ 34
4.7. Integración con la aplicación de mantenimiento ..................................................................... 35
4.8. Requisitos de Capacidad y Escalabilidad ................................................................................ 36
4.9. Requisitos de Fiabilidad y Rendimiento .................................................................................. 36
4.10. Requisitos de Administración y Acceso .................................................................................. 37
4.11. Requisitos de Presentación ................................................................................................... 37
4.12. Requisitos Tecnológicos. ...................................................................................................... 39
4.13. Formación y Documentación ................................................................................................ 40
4.14. Mantenimiento de la aplicación. ............................................................................................ 41
5. APLICACIÓN DE MANTENIMIENTO. .......................................................................... 42
3 de 66
5.1. Funcionalidades generales de Gestión de Mantenimiento de Red. ............................................ 42
5.2. Funcionalidades de Mantenimiento Preventivo. ...................................................................... 42
5.3. Funcionalidades de Mantenimiento Correctivo. ....................................................................... 45
5.4. Funcionalidades de Gestión DE PROCESOS Y DEFINICION DE WORKFLOWS............................. 46
5.5. Funcionalidades de Gestión Documental. ............................................................................... 47
5.6. Funcionalidades de reporting/informes .................................................................................. 47
5.7. Integración con el ERP corporativo de Itelazpi ....................................................................... 48
5.8. Integración con el ERP de altel ............................................................................................. 49
5.9. Integración con la aplicación de inventario ............................................................................ 49
5.10. Requisitos de Capacidad y Escalabilidad ................................................................................ 49
5.11. Requisitos de Fiabilidad y Rendimiento .................................................................................. 50
5.12. Requisitos de Administración ................................................................................................ 51
5.13. Requisitos de Acceso y Presentación ..................................................................................... 51
5.14. Requisitos Tecnológicos. ...................................................................................................... 52
5.15. Formación y Documentación ................................................................................................ 52
5.16. Mantenimiento .................................................................................................................... 53
6. METODOLOGIA. ......................................................................................................... 54
6.1. Equipo de Proyecto y cualificacion tecnica del licitador ............................................................ 54
6.2. Plan de Proyecto ................................................................................................................. 58
7. ASPECTOS MEDIOAMBIENTALES. ............................................................................. 60
8. ASPECTOS RELATIVOS A LA PREVENCIÓN DE RIESGOS LABORALES. ...................... 61
9. TRATAMIENTO DE DATOS DE CARÁCTER PERSONAL................................................ 62
10. SECRETO Y CONFIDENCIALIDAD. ............................................................................. 63
11. PRESUPUESTO DE LA LICITACION Y PLAZO DEL CONTRATO. ................................. 64
12. PRESENTACION DE LAS OFERTAS. ............................................................................ 65
4 de 66
1. OBJETO.
1.1. ANTECEDENTES.
ITELAZPI, Sociedad Pública dependiente del Departamento de Hacienda y Finanzas del Gobierno
Vasco, es una empresa que tiene entre sus objetivos la prestación de servicios de
radiocomunicaciones de distinta índole a las diferentes administraciones públicas de la Comunidad
Autónoma de Euskadi (CAE). Para ello, dispone de una infraestructura pública de más de 250
emplazamientos o centros de comunicaciones en puntos dominantes de la geografía. Asimismo,
dispone de una red de transmisión digital de alta capacidad entre la mayoría de dichos
emplazamientos. Esta infraestructura pública, gestionada y operada por ITELAZPI, es la base para la
prestación de los servicios a las entidades clientes.
Entre los principales servicios prestados por ITELAZPI se encuentran los siguientes:
• Servicios de broadcast (radio y tv digital). Principalmente para el grupo EiTB, pero también para
otros difusores públicos y privados.
• Servicios de radiocomunicaciones profesionales mediante tecnología TETRA.
• Servicios de acceso Internet rural. Proyecto “Konekta Zaitez @ Banda Zabala”, en colaboración
con Euskaltel.
• Servicios de alojamiento o albergue en los emplazamientos de sistemas de comunicaciones de
terceros.
Itelazpi ha realizado un diagnóstico acerca de la gestión de activos de la compañía y los principales
procesos de operación de la misma, y se han llegado a conclusiones que derivan en las siguientes
acciones de mejora.
• Centralizar los repositorios de inventario de activos.
• Oportunidad de mejora en la codificación común de activos, continuando con la tarea iniciada
con los identificadores de centros.
• Mejorar la gestión de la documentación asociada a los activos o procesos, buscando mayor
homogeneidad en la definición de qué información, proceso, actividad se documenta, ubicación
y acceso a la documentación.
• Mejorar la gestión de los trabajos de mantenimiento alrededor de los servicios o
infraestructuras: tales como preventivos, correctivos, cambios, gestión de material… buscando
la homogeneización. así como mejoras en las herramientas para ejecutar procesos, para
acabar eliminando mecanismos no formales de SSII tales como Excel/Access.
5 de 66
Para qué se quiere implementar el proyecto de Gestión Integrada de Activos (GIA):
• Cuadro de Mando Corporativo en Activos
• Indicadores de Proceso en Activos
• Seguimiento legal, económico, técnico y patrimonial de centros y equipamientos
• Organizar y dar acceso fácil a todos a la documentación corporativa que se requiere
• Repositorio y codificación única para la gestión de cada proceso
• Seguimiento de mantenimiento de los centros: preventivos, correctivos.
• Seguimiento ciclo de vida de los activos: despliegue, garantías, reparaciones, repuestos…
1.2. ALCANCE DEL CONTRATO.
Se pretende acometer un proyecto de mejora tecnológica mediante la implantación de una
herramienta informática (o conjunto de herramientas) que permita una gestión integral de activos
(GIA) unificada para todos los procesos de la compañía.
La red sobre la que se presta el servicio objeto de esta herramienta comprende el total de
emplazamientos de radiocomunicaciones gestionados por ITELAZPI, incluyendo tanto su
infraestructura física: pista de acceso, casetas, recinto, torres… como los sistemas de energía y
telecomunicaciones instalados para la prestación de los servicios de ITELAZPI desde dichos
emplazamientos. Asimismo, se incluyen los sistemas de telecomunicaciones responsabilidad de
ITELAZPI instalados en centros de terceros, tanto en emplazamientos de radiocomunicaciones de
otros operadores como en instalaciones de clientes de ITELAZPI: estudios de EiTB, estaciones de
Metro Bilbao, túneles ferroviarios, etc.
El proyecto se subdivide en dos ámbitos principales, el INVENTARIO de la red y su MANTENIMIENTO.
Por ello, y dado que se trata de dos bloques funcionalmente diferentes, se contempla la implantación
de dos herramientas independientes. No obstante, ambas deben estar estrechamente
interconectadas, por lo que su suministro e implantación deben ser ejecutados por un único proveedor
adjudicatario.
Está dentro del alcance de esta licitación:
• Una primera fase de análisis y diseño de detalle de la solución a implantar.
• El desarrollo, suministro e implantación de una aplicación de inventario de los activos de
Itelazpi, así como su integración con las aplicaciones informáticas corporativas existentes. Se
debe realizar previamente el diseño del modelo de datos más adecuado, y su implantación en la
6 de 66
Base de Datos del inventario. Debe incluir además la gestión documental relacionada con los
activos.
• El suministro y parametrización de una aplicación de mantenimiento de los activos de
Itelazpi, así como su integración con el anterior software de inventario y con el software de
gestión empresarial (ERP) existente en Itelazpi. Debe incluir además la gestión documental
relacionada con las tareas de mantenimiento.
• El apoyo en la gestión del cambio asociado a la implantación de estas aplicaciones
• La formación a nivel de usuarios y de administrador de las nuevas aplicaciones.
• La garantía, coste de licencias y actualizaciones de versión en los dos ejercicios siguientes a la
entrega del proyecto.
7 de 66
2. DESCRIPCION DE LA RED DE ITELAZPI.
La red sobre la que se presta el servicio objeto de esta contratación comprende el total de
emplazamientos de radiocomunicaciones gestionados por ITELAZPI, incluyendo tanto su
infraestructura física: pista de acceso, casetas, recinto, torres… como los sistemas de energía y
telecomunicaciones instalados para la prestación de los servicios de ITELAZPI desde dichos
emplazamientos. Asimismo, se incluyen los sistemas de telecomunicaciones responsabilidad de
ITELAZPI instalados en centros de terceros, tanto en emplazamientos de radiocomunicaciones de
otros operadores como en instalaciones de clientes de ITELAZPI: estudios de EiTB, estaciones de
Metro Bilbao, túneles ferroviarios, etc.
2.1. CENTROS DE COMUNICACIONES. SERVICIO DE ALBERGUE.
El ámbito geográfico de los centros de ITELAZPI se circunscribe a la CAE y límites circundantes, con la
excepción de los sistemas de difusión de radio y de televisión en Navarra.
Para aportar una estimación del volumen de emplazamientos, se presenta a continuación un listado
del número de emplazamientos propios y de terceros con sistemas de ITELAZPI:
Tipo de emplazamiento, por
titularidad
Cantidad
ITELAZPI 225
Municipales 28
Municipales Navarra 41
Otros operadores (móviles, Abertis…) 109
De cliente (EiTB, Metro Bilbao…) 140
La base de emplazamientos propios genera en ITELAZPI la actividad de Albergue. Se gestionan 225
centros propios de comunicaciones repartidos a lo largo de la geografía vasca. Estos centros gozan de
elevados estándares de mantenimiento, que garantizan un alto nivel de comodidad en su utilización,
incluyendo:
• energía protegida
• climatización
• seguridad
• accesibilidad
8 de 66
La compartición de infraestructuras forma parte de nuestro compromiso medioambiental, ya que su
aplicación favorece la racionalización del uso de los espacios naturales para la implantación de
servicios de comunicaciones. Con tal fin, ITELAZPI ha promovido alianzas de compartición con varios
agentes del sector.
Los centros se categorizan en función de su importancia estratégica para el servicio o de su tamaño,
siendo los C1 los centros principales y, en el otro extremo, los C4 los centros menos importantes y con
menos infraestructura física.
Tipo de emplazamiento ITELAZPI, por
categorización
Cantidad
C0 (Sede y almacén ITELAZPI) 2
C1 10
C2 37
C3 124
C4 54
El proceso de Albergue y Energía es el principal implicado en la gestión de los centros de Itelazpi. No
obstante, todos los restantes procesos operativos de Itelazpi toman la información acerca de los
centros como la base geográfica, física y lógica de su actividad. Se puede decir que es el núcleo de la
actividad de Itelazpi.
Es también especialmente importante la documentación patrimonial de cada centro (proceso
Jurídico/legal), en la que se debe registrar la titularidad y particularidades de cada centro, en cada
uno de sus componentes esenciales: centro, terreno, acceso, infraestructura, etc.
El proceso de Albergue gestiona la relación con los clientes que alojan sus sistemas en los
emplazamientos de Itelazpi. Para la determinación del coste del servicio se tienen en cuenta los
siguientes parámetros:
• Tipo de Centro
• Consumo (W)
• Metros lineales de ocupación de torre por cada antena
• M2 de ocupación en Planta de sistemas en la caseta interior o recinto. También se computan
unidades de altura de ocupación en rack compartidos.
El proceso de Albergue gestiona también el alojamiento de sistemas de Itelazpi en emplazamientos
de terceros, en un proceso simétrico al anteriormente descrito.
9 de 66
2.2. CENTROS DE COMUNICACIONES. SUBSISTEMA DE ENERGÍA.
El subsistema de energía comprende todos los elementos que permiten la disponibilidad de suministro
eléctrico para los sistemas de telecomunicaciones alojados en los emplazamientos de ITELAZPI. Los
elementos principales son los siguientes:
• Puntos de entrega del suministrador eléctrico (Iberdrola en la actualidad).
• Líneas de acometida eléctrica propias de ITELAZPI de alta y baja tensión. Llevan el suministro
eléctrico desde el arranque de línea, hasta el centro.
• Centros de transformación y transformadores-separadores propios, en algunos casos.
• Grupos electrógenos (10 en C1, 37 en C2, 4 en C3). Se dispone de un SCADA con supervisión
remota a través de un sistema de PLC en cada grupo.
• Protecciones atmosféricas. Descargadores.
• Pararrayos y tomas de tierra.
• Cuadros de distribución general de AC y CC.
• Líneas generales de distribución de alterna y de cc, dentro del centro.
• Rectificadores y baterías
• Varios (alumbrado, tomas de corriente, ventilación, balizamiento….)
Cada uno de los elementos consta de diferentes subelementos, todos ellos susceptibles de ser
inventariados y de relacionarse con tareas de mantenimiento. Como ejemplo, se pueden tomar los
módulos de potencia de un rectificador.
10 de 66
2.3. SUBSISTEMA DE TRANSPORTE.
El sistema de transporte está integrado por una red de fibra óptica, una red de radioenlaces SDH de
alta capacidad, una red de radioenlaces PDH de baja capacidad y otro equipamiento asociado a las
citadas redes o que complementa la funcionalidad de las mismas. Es la infraestructura común que
posibilita la transmisión para los servicios de telecomunicaciones prestados por ITELAZPI.
A modo orientativo, se indica que la red de alta capacidad SDH está integrada a la fecha del presente
Pliego por 53 Radio-enlaces, cuatro equipos DWDM y 75 OMSNs. La red de baja capacidad PDH está
conformada por 134 radioenlaces. A ellos hay que añadir todo el equipamiento de codificación de
vídeo y audio, y transporte de datos para supervisión.
Un radioenlace es en realidad un objeto lógico que tiene dos componentes principales, un equipo en
cada centro extremo. A su vez, cada equipo se descompone en elementos: equipo de interior, de
exterior (IDU y ODU), módulos de la IDU, parábola en torre, etc.
El OMSN es el equipo de conmutación SDH que gestiona los circuitos lógicos entre enlaces. Existe al
menos uno en cada centro de la red SDH. Consta de múltiples subcomponentes como módulos del
equipo.
La red de transporte de ITELAZPI está dividida en dos partes bien diferenciadas:
a) Red troncal.
b) Red capilar.
a) La Red troncal está basada en Radio-Enlaces SDH de Alcatel, modelo LSY de última generación,
funcionando en las bandas de frecuencia de 6,8, 13 y 18 GHz, y en dos enlaces interprovinciales
DWDM, de la marca ADVA (mod.FSP 2000), sobre Fibra Óptica, que unen las tres capitales vascas,
Bilbo, Gasteiz y Donostia.
Esta capacidad de transporte se gestiona con unos Nodos Multiservicio de Alcatel (1642, 1650, 1662 y
1660), dando las funcionalidades de redundancia automática, calidad de servicio e información del
mismo necesarios, y controlado todo ello desde un gestor 1353 NM, ubicado en ITELAZPI.
b) La Red capilar está basada en Radio-enlaces de Baja capacidad, de los fabricantes Siemens (mod.
SRAL-XD) y Alcatel (mod.AWY), de última generación. Ambos equipos disponen de interfaces PDH y
Ethernet.
Todo el parque de equipamiento Alcatel se gestiona a través de la aplicación de supervisión y
configuración de Alcatel NM1353.
11 de 66
Los servicios principales a los que da soporte la red de transporte son los siguientes:
• Emisiones y contribuciones de TV analógica y TDT, EiTB. (Incluye codificación y adaptación de
red, con equipamiento MPEG-2, de la marca TANDBERG)
• Programas de radio FM (Incluye codec de audio, mod. INTRAPLEX de Harris)
• Red WIMAX, proyecto KZ@BZ.
• Red TETRA de ITELAZPI.
• Red de supervisión de ITELAZPI.(Incluye switches Ethernet Cisco y Alcatel, modelos 500, 2950
y 3500)
• Servicios de transporte a terceros.
2.4. SUBSISTEMA DE DIFUSIÓN.
El sistema de difusión está integrado por los equipos y elementos que soportan las emisiones de
televisión analógica, televisión digital terrestre, frecuencia modulada, onda media y otros sistemas o
elementos relacionados con estos servicios. Los componentes principales son los siguientes:
• Sistemas radiantes y elementos de torre (para todos los transmisores y reemisores).
• Transmisores y reemisores de TDT
• Multiplexores de TDT
• Transmisores de radiodifusión FM
• Radioenlaces de FM 1600
• Red voting
• Receptores de satélite de TDT en centros
• Sistema de monitorado Audemat.
El servicio principal es la radiodifusión de la radiotelevisión autonómica pública vasca, del grupo EiTB.
No obstante también se prestan servicios de difusión a operadores de radio privados y se emiten en
múltiples puntos el resto de canales de TV nacionales.
2.5. SUBSISTEMA DE WIMAX.
El proyecto “Konekta Zaitez @ Banda Zabala” es una iniciativa incluida dentro del “Plan Euskadi en la
Sociedad de la Información” (PESI), cuyo lanzamiento tuvo lugar en 2004 y que ha contribuido hasta
la actualidad a disminuir la brecha digital entre las poblaciones principales y las zonas rurales más
desatendidas en cuanto a la disponibilidad de acceso Internet de banda ancha.
12 de 66
La red de acceso de tecnología WiMAX se compone de 103 estaciones base (BTS) de WiMAX fijo
802.16d. Las BTS son equipamiento BreezeMAX 3500 del fabricante Alvarion. Estas BTS proporcionan
cobertura de servicio en las zonas rurales de la CAE, no atendidas por los operadores privados.
Toda la infraestructura de telecomunicaciones: emplazamientos, red de transporte, red de acceso es
de titularidad pública, a través de ITELAZPI. Euskaltel se encarga de la comercialización del servicio, la
atención al cliente y de las instalaciones de los equipos terminales de cliente. ITELAZPI entrega el
tráfico de Internet a Euskaltel en tres puntos de interconexión, uno por provincia.
Dado que está estrechamente ligado a la provisión del servicio, Euskaltel suministró a ITELAZPI las
estaciones base WiMAX que componen la red de acceso y dotan de cobertura a las zonas rurales
objetivo del proyecto. Asimismo, se encarga de su operación y mantenimiento. Por ello, el CAU
coordina conjuntamente, con Euskaltel como resolutor, incidencias en la red WiMAX. Y, a la inversa,
ITELAZPI presta el servicio de transporte a Euskaltel para estas BTS.
2.6. SUBSISTEMA DE TETRA.
La red Tetra de ITELAZPI está basada en el estándar ETSI que define las radiocomunicaciones
móviles terrestres en modo trunking. Su objetivo es la prestación de servicios de radiocomunicaciones
móviles profesionales a las administraciones de la CAE. Su cobertura abarca toda la Comunidad
Autónoma de Euskadi. Está compuesta de dos partes diferenciadas:
• Dos nodos de conmutación (NC) principales, ubicados en ITELAZPI y en Vitoria, proporcionando
redundancia de conmutación.
• 137 Estaciones Base (BTS), repartidas en emplazamientos de telecomunicaciones por toda la
geografía.
La red de transporte de ITELAZPI soporta la transmisión necesaria entre las BTS y los dos NC.
Asimismo existe una infraestructura común en el CPD de ITELAZPI, en la que se alojan las
aplicaciones de localización, facturación y transmisiones de datos de clientes con acceso directo a la
infraestructura TETRA.
13 de 66
2.7. SUBSISTEMA DE SISTEMAS DE INFORMACIÓN.
De acuerdo a la naturaleza de ITELAZPI, el área de sistemas de información gestiona los siguientes
ámbitos tecnológicos:
• Aplicaciones software de usuario final, entendidas como la piezas de código software,
desarrolladas a medida o formando parte de un paquete comercial, que contiene la
funcionalidad que el usuario requiere para el desempeño de sus funciones. Dentro de esta
familia tecnológica distinguimos los siguientes ámbitos de especialización:
- Aplicaciones software de soporte a las operaciones (en lo que sigue Aplicaciones OSS).
- Aplicaciones software de soporte a la gestión empresarial y a la estrategia (en lo que sigue
Aplicaciones empresariales).
- Aplicaciones de integración, que si bien no dan servicio al usuario final son necesarias para
que todo el conjunto funcione de una manera eficiente.
• Infraestructuras de sistemas de información entendida como el conjunto de componentes
físicos, hardware (redes, servidores, almacenamiento,….) y código software (sistemas
operativos, dns, directorios, middleware, integración, …) necesarios para que las aplicaciones
software puedan operar adecuadamente, pudiendo estar ubicados en el lado del cliente
(Microinformática) como del servidor.
• Sistemas de seguridad de la información. Se refiere a los controles técnicos (firewalls, vpn,…)
(tanto software como hardware) que garantizan la seguridad de las operaciones.
2.8. SUBSISTEMA DE INFRAESTRUCTURAS DE CENTRO.
En este subsistema se incluyen elementos o componentes físicos relacionados con cada centro, que
requieren de una serie de revisiones o inspecciones, en muchos casos obligatorias por Ley, y
generalmente relacionadas con la prevención de riesgos laborales y la seguridad, como pueden ser los
extintores, depósitos de gasoil o líneas de vida. Todos ellos, son susceptibles por tanto, de un
inventario y trazado exhaustivo, y se hace imprescindible el seguimiento de las tareas periódicas
relacionadas.
2.9. SUBSISTEMA DE INFRAESTRUCTURAS DE FIBRA ÓPTICA.
Es muy posible que en un breve plazo de tiempo Itelazpi reciba una encomienda del Gobierno vasco
para gestionar la infraestructura de telecomunicaciones para fibra óptica, de la que es titular en
conjunción con Euskaltel.
14 de 66
Esta infraestructura consta de más de 1.000 Km de canalizaciones sobre vías públicas, carreteras,
trazados ferroviarios, etc. Cada tramo de canalización se divide en segmentos, que son los subtramos
que intercomunican las arquetas de acceso y trabajo. Cada segmento tiene unas conductos, en los
que de puede instalar o tender un cable de telecomunicaciones, típicamente de fibra óptica. Itelazpi
deberá llevar el control de la ocupación de los conductos que son de su competencia, pudiendo
incluso iniciarse una línea de negocio en cuanto a su explotación por áreas del Gobierno Vasco y por
terceros.
2.10. RESUMEN DE ACTIVOS.
A continuación se listan los activos de todos los subsistemas, con las tareas periódicas típicas que se
realizan sobre ellos.
Entorno Elementos Inventariado Cantidad Frec. anual aprox. tareas periódicas
Documentación asociada
Patrimonio Centro 225 Decretos, Expdtes, Fichas (pdf)
Terreno 225
Acceso 225
Infraestructura 225
Albergue / Patrimonio
Datos Generales de Centro Itelazpi 225 Planos de Centro AutoCAD y PDF
Datos generales de Centro Totales 564 Planos de acceso a Centro (km)
Clientes de Albergue 33 Planes de Emergencia (pdf)
Equipos albergados 1712 Evaluación de riesgos de centro (pdf)
Servicios albergados 92 Docs de procedimiento de Instalaciones de albergue (ShP)
Energía Contratos Iberdrola, potencia, consumos 168 1
Grupo electrógeno + PLCs 46 según tipo de centro
UPS 56 1
Rectificadores 172 1
Onduladores 1
Baterías 172 1
Cuadros (desglosado) 225 1
Líneas de alta/baja 225 Proceso de inventariado y documentación de líneas (Sergio)
Obras/Infraestr. Aire Acondicionado 119 1 Informes visado de esfuerzo de torres (pdf + Autocad)
Extintores 738 1, trianual, quinquenal Certificados depósitos de gasoil
Depósitos principales 46 1 Fichas técnicas de elementos químicos
15 de 66
Entorno Elementos Inventariado Cantidad Frec. anual aprox. tareas periódicas
Documentación asociada
Geotextiles 225 1
Líneas de vida 222 1
Acceso (llaves) 470 1
Pararrayos 71 1
Depósitos de diario 26 2
Vehículos de empresa 9 1
Transporte Radioenlaces SDH 53 4 Según importancia del centro
Manuales de equipamiento
Radioenlaces PDH 134 2 Aceptaciones
Nodos SDH 75 4
Codecs TV, FM 84 2
Switches LAN supervisión 38 2
Broadcast TDT Transmisor (Sist. Rad, Mux) 49
6 Según importancia del centro As Builts de TDT (Telco, Altel)
TDT Regenerador 43 2 Doc Planta Externa (en construcción) pdfs
TDT Gapfiller 52 2
TDT MTR (receptor satélite) 84 2
TDT Albala (GPS) 34 2
TDT UPS 67 2
Supervisores BTESA 75 2
Monitorado Audemat 146 2
FM Transmisor 18 4
TETRA BTS TETRA 163 2 Datos de preventivos. As-Builts.
KZBZ BTS WiMAX 103 0 As-Builts
Sistemas Servidores físicos 10 0 CMDB en formato Excel Mapas de red en formato PowerPoint
Máquinas virtuales 25 0
Equipos comunicaciones 8 0
Red Fibra GV Arqueta 39984 2 GIS, Fotos
Segmento 56789 1
Conducto 307792 1
Cable/Sección 77717 1
16 de 66
3. DESCRIPCION DE LOS SISTEMAS DE OPERACION DE LA RED DE ITELAZPI.
A continuación se describen los sistemas actuales de operación y monitorización de ITELAZPI y su
funcionalidad. Se describe la operativa actual sobre ellos desde el servicio de CAU, es decir, a cuales
de dichos sistemas accede y con qué propósito.
3.1. SISTEMAS DE GESTIÓN ESPECÍFICOS POR TECNOLOGÍA.
Dada la disparidad de tecnologías de comunicaciones gestionadas por ITELAZPI, existe una
importante diversidad de gestores por entorno. Cada gestor es, en general, una aplicación propietaria,
o adaptada específicamente para la operación y monitorización del subsistema. A continuación se
incluye una tabla con una enumeración de los subsistemas de gestión y su descripción.
Subsistema Gestor Descripción de la funcionalidad
Energía/Albergue
Scada Genelek Estado de los grupos electrógenos, calidad suministro eléctrico, botón arranque en frío del grupo….
Rectificadores Alarmas de energía por entradas de contacto de los equipos de transporte
Housekeeping de centros sin transmisión, via TETRA
Aplicación de recepción de eventos de housekeeping: apertura de puertas, caída de red, alarmas del transmisor de difusión.
Transporte
Alcatel 1353NM Monitorización y operación de la red SDH y PDH Alcatel.
Siemens Netviewer Monitorización u operación de la red PDH Nokia-Siemens
Tandberg TDC Monitorización y operación de la red de codiifcadores de video Tandberg.
Difusión
BTESA Monitorización y Operación de los transmisores BTESA. Alarmas de housekeeping en centros.
Otros (Mier, Rohde, Diratel) Monitorización y operación de transmisores via browser
TETRA Teltronic NMS Estado y configuración de la red TETRA
General SNMPc CastleRock Polling básico de estado y alarmas con MIB compiladas de diferentes servicios: BTS WiMAX, TETRA, red de supervisión, transmisores difusión…
Sistemas NAGIOS Polling avanzado de disponibilidad de servicios TIC de ITELAZPI.
17 de 66
3.2. SISTEMA NETCOOL DE CONSOLIDACIÓN DE ALARMAS.
La aplicación Netcool es la base para la monitorización del estado de la red de ITELAZPI. Los
operadores del CAU supervisan permanentemente esta aplicación para detectar nuevas alarmas o
eventos de red que puedan delatar una incidencia en el servicio. La aplicación realiza tres funciones
principales:
• Recolección del estado y los eventos originados en los diferentes gestores o equipos a
integrar y enviarlos al ObjectServer (procesador principal de la aplicación). Esta fase realiza
además el enriquecimiento de los eventos a partir de la información proporcionada por tablas
de cada ámbito, de forma que se especifique el centro, la categoría del centro, el servicio, ....
• Consolidación: lleva a cabo las tareas de recepción y almacenamiento de los eventos
enviados desde las sondas y agentes SSM.
• Presentación: contiene los elementos encargados del acceso a los datos almacenados, para
su visualización y/o edición. Dentro de este área funcional distinguimos los siguientes
elementos:
- 1 Desktop nativo en Linux: que permite visualizar, editar, organizar y filtrar los eventos
almacenados en el ObjectServer.
- 1 Webtop con múltiples licencias DT: permite el acceso de múlitiples usuarios
simultáneamente a los eventos del ObjectServer mediante páginas web customizables. Es el
utilizado por los operadores del CAU.
- 1 Netcool/Reporter: es la herramienta encargada de la generación y presentación de
informes de históricos a partir de la información almacenada en la base de datos MS SQL
Server.
ARQUITECTURA FUNCIONAL
SNMPc
PDHRectificadores
PDHRectificadores
CodecsVideo
CodecsVideo
Grupos Electrógenos Autómatas
Grupos Electrógenos Autómatas
Transmisores
TV / Radio
Transmisores
TV / Radio
REDES
1353NM BTESASSM Agent TDC
PlataformaGenelek SSM Agent
SIEMENSNetviewerSSM Agent
SDHSDH
Equipos ADVA, Intraplex
Equipos ADVA, Intraplex
DCNRed
Gestión
DCNRed
Gestión
NetcoolServer1NetcoolServer1Linux ES 3Linux ES 3
NetcoolServerReporterNetcoolServerReporter(Windows 2000 Server)(Windows 2000 Server)
GESTORES DE ELEMENTOS
RECOLECIÓN
CONSOLIDACIÓN
PRESENTACIÓN
ObjectServer
Gateway
Alcatel OSOS MTTRAPD
MTTRAPD
MS SQL Server 2000
Linux Desktop WEBTOP - 5 DesktopsREPORTER
SSM AgentSSM
Agent
18 de 66
Los operadores del CAU disponen de una interface web con actualización permanente de los eventos
activos en la red con una criticidad alta o máxima, y deben reaccionar ante su aparición siguiendo las
instrucciones del procedimiento correspondiente. El aspecto de la pantalla es el siguiente:
La actualización de los datos de entrada para el enriquecimiento de eventos en Netcool se realiza
mediante unas tablas denominadas de Lookup, que son alimentadas desde una CMDB basada en SQL
Server. Esta CMDB de Netcool no está integrada en la actualidad con ninguna otra fuente de
información externa.
19 de 66
3.3. APLICACIÓN SERVICE MANAGER DE GESTIÓN DE INCIDENCIAS.
La herramienta utilizada en la actualidad por el CAU de ITELAZPI permite la apertura, seguimiento y
cierre de incidencias, así como la creación posterior de informes y estadísticas sobre el servicio.
Cada ticket generado a partir de una o varias llamadas contiene los siguientes campos:
• Código de ticket asignado por la aplicación
• Nombre del registrador (operador del CAU)
• Fecha y hora de registro de ticket
• Fecha de comienzo de ticket
• Fecha de finalización de ticket
• Territorio Histórico
• Categoría: Avería, consulta o problema
• Dominio: alimentación, comunicaciones, difusión, infraestructura, sistemas de información,
TETRA, transporte, otros.
• Tipo y subtipo dentro del dominio correspondiente (p.ej. Dominio Transporte, Tipo Transporte
PDH, subtipo Banda Zabala)
• Resumen y descriptivo de la incidencia
• Cáculo de severidad: usuarios afectados, solución provisional, severidad, nº de incidencias.
• Estado: Abierta, Pdte, Terminado, Cerrado.
• Listado de Acciones, cada una con datos de: estado, tipo de acción, fecha
comienzo/finalización, resumen, descripción, resolutor, duración…
La aplicación Service Manager forma parte de la suite System Center 2012 de Microsoft, y está
implantada en la infraestructura de TI de Itelazpi. Su arquitectura funcional es la siguiente:
20 de 66
La BD de SM contiene una CMDB con varios ítems o CIs. En la actualidad, no existe conexión con
tablas o bases de datos externas de esta aplicación, por lo que la actualización de información se
debe efectuar desde la consola de administración.
Las tablas y CIs más importantes de esta CMDB de SM relacionadas con el inventario de Itelazpi son
las siguientes:
CENTROS
Se trata de la información primordial para la creación de una incidencia, ya que se trata del dato del
emplazamiento en el que se tiene un problema. Se trata de un CI crítico, ya que no se puede cerrar
ninguna incidencia sin que se haya indicado cual es el centro afectado. A continuación se muestran
unos ejemplos:
IDBASEDEDATOS 1 2 3
IDCENTRO 0IT101 0IT102 1IT001
CATEGORIA 0 0 1
CATEGORÍA BROACAST - - A
CATEGORÍA TETRA C
TITULARIDAD Itelazpi Itelazpi Itelazpi
ALIAS-COMENTARIOS ALMACEN DE ITELAZPI
NOMBRES ITELAZPI ITELAZPI-TORRELARRAGOITI GANETA
DIRECCION IBAIZABAL BIDEA-EDIFICIO 101 Poligono Torrelarragoiti pabellon 6 C/Monte Ganeta, 4 bajo 1
CP 48170 48170 48810
POBLACION ZAMUDIO ZAMUDIO ALONSOTEGI
MUNICIPIO ZAMUDIO ZAMUDIO ALONSOTEGI
PROVINCIA BIZKAIA BIZKAIA BIZKAIA
X-REVISADAS 511350 511227 504237
Y-REVISADAS 4793055 4791896 4785424
LAT-GRADOS 43 43 43
LAT-MINUTOS 17 16 13
LAT-SEGUNDOS 24,845 47,3 17,732
LONG-GRADOS -2 -2 -2
21 de 66
LONG-MINUTOS 51 51 56
LONG-SEGUNDOS 36,322 41,9 52,179
TORREm ___ ___ 56
TIPOTORRE ___ ___ CELOSIA
CROQUISACCESO No No Sí
GOOGLEKML No No Sí
KEYBOX No No Sí
CONTACTO
REVISADO 11/02/2013 29/09/2009
BAJA NO NO NO
OBSERVACIONES
SUBSISTEMAS
El CI Subsistemas incluye los diferentes subsistemas a los que se puede asociar una incidencia:
• Centros - Albergue
• Centros - Energía
• Broadcast
• Transporte
• WiMAX
• TETRA
• Sistemas TI
PRODUCTOS
Una descripción muy general de lo que se propone recoger en este CI “Producto”, podría ser que se
trata del CATALOGO de SERVICIOS que Itelazpi ofrece a sus Clientes (tanto internos como
externos). Estos servicios son los que pueden sufrir una afección (corte o degradación) en las
incidencias que se tengan en la red de Itelazpi.
A modo de resumen, se tienen distintos ámbitos de productos que se ofrecen a los clientes de
Itelazpi:
• Servicio de Broadcast: MUX ETB, SFNs, RGE, MPE, FMs, OM… etc
• Servicios de Albergue (incluye implícitamente el servicio de energia).
• Servicios de Transporte.
• Servicios de TI
22 de 66
RELACION
Se dispone de una “tabla” en la CMDB donde se indican qué servicios están contratados. Esta “tabla”
relaciona los distintos Cis indicados anteriormente y añade información relevante del contrato, como
puede ser el SLA acordado por parte de Itelazpi con el cliente.
En cuanto a los campos del CI Relación:
Nombre Tipo Descripción
NOMBRE DE CENTRO Relación CI Centro
SUBSISTEMA Relación CI Servicio. Se trata del tipo de servicio que se
ha contratado.
CLIENTE Relación CI Cliente. El cliente que ha contratado el
servicio.
PRODUCTO Relación CI Producto
NOMBRE DEL SERVICIO
TIEMPO DE CORTE
(MINUTOS) PERMITIDO PARA
TAREAS PREVENTIVAS.
Numérico Se trata de un indicador del SLA. Con este
valor, se indica en minutos el tiempo máximo
anual que el cliente autoriza a Itelazpi para
realizar cortes debido a tareas programadas.
% DE DISPONIBILIDAD Numérico Se trata de un indicador del SLA. Se indica el
porcentaje anual de disponibilidad que se ha
acordado. Se trata de un indicador anual.
TIEMPO MÁXIMO DE CORTE
(MINUTOS) ANTES DE
INCUMPLIR LA
DISPONIBILIDAD
Numérico Se trata de la traducción a minutos del % de
disponibilidad del atributo anterior.
TIEMPO TOTAL DE CORTE
(permitido + no permitido)
Numérico Se trata de la suma de: TIEMPO PREVENTIVO
+ TIEMPO CORTE. Para tener una información
directa del tiempo total antes de incumplir con el
% de disponibilidad.
PONDERACIÓN Numérico. Valor que representa la importancia que tiene
ese centro para el servicio contratado.
COBERTURA DEL SERVICIO. Lista seleccionable Se informa el tipo de atención ESPECÍFICA que
se tiene con el servicio contratado. Puede ser
23 de 66
[8x5, 24x7] diferente de la cobertura indicada en el catálogo
del servicio.
RESPONSABLE N1 String Nombre de la persona que podría atender en
primer nivel alguna incidencia relacionada con
este servicio.
TELÉFONO N1 Numérico Teléfono del responsable N1
RESPONSABLE N2 String Nombre de la persona que podría atender en
segundo nivel alguna incidencia relacionada con
este servicio.
TELÉFONO N2 Numérico Teléfono del responsable N2
RESPONSABLE N3 String Nombre de la persona que podría atender en
tercer nivel alguna incidencia relacionada con
este servicio.
TELÉFONO N3 Numérico Teléfono del responsable N3
CLIENTES
EQUIPOS
Actualmente no se dispone ningún campo en este CI para poder relacionar las incidencias con los
equipos afectados, y no se está usando. Por tanto no se alimenta ahora de ningún elemento externo.
Para importar los valores a la CMDB del SM, se realiza una carga manual a través de un fichero CSV
con los campos que se decidan de la BBDD. En esa importación también se define un fichero XML
donde se relacionan los campos de la BBDD origen con la CMDB destino. Este método no automático
se ha utilizado en la primera carga de datos del SM. Ejemplo del archivo XML:
24 de 66
3.4. SOFTWARE DE GESTIÓN EMPRESARIAL ERP.
Itelazpi opera desde el año 2004, un software de gestión empresarial (ERP) corporativo, denominado
RPS. RPS es el ERP desarrollado por Ibermática para las Pymes Industriales y de Distribución. Se trata
de un sistema modular, concebido para soportar todos los procesos de la compañía. La versión es RPS
2013, y se han activado las siguientes licencias de funcionalidades:
• • Módulo de Workflow.
• • Módulo de Business Intelligence.
• • Módulo de Gestión de Compras (pedidos).
• • Módulo de Gestión de Ventas (facturación).
• • Módulo de Contabilidad.
• • Módulo de Tesorería.
En la actualidad esta aplicación informática no está integrada con un inventario de equipamiento.
Tampoco hay establecidas relaciones entre sus módulos y las acciones de mantenimiento preventivo y
correctivo. No obstante, la arquitectura de la solución está basada en tecnología de última generación
100% SOA para interoperar con Servicios Web de otras aplicaciones.
3.5. TABLAS Y BASES DE DATOS OFIMÁTICAS.
Al no existir un inventario corporativo, cada proceso maneja internamente los datos que se precisan
para la gestión de sus activos, su mantenimiento y la documentación asociada. En la siguiente tabla
se resume la situación de cada proceso, los activos con los que se trabaja, el método de inventariado,
de seguimiento de mantenimiento, gestión documental y de repuestos.
25 de 66
En general, el grado de integración actual entre estas tablas es muy bajo. Tan solo se han acometido
ciertas actuaciones puntuales de obtención de los listados y códigos unificados de centros de la BBDD
de Albergue, desde los ficheros de energía, patrimonio, broadcast y CMDB de Netcool.
26 de 66
4. APLICACIÓN DE INVENTARIO.
El adjudicatario deberá diseñar, desarrollar e implementar una aplicación de inventario en Itelazpi, de
acuerdo a los requisitos expuestos en este Apartado.
4.1. DEFINICIÓN Y MODELADO DE ACTIVOS.
El adjudicatario colaborará con el personal técnico de Itelazpi en la definición del modelo de datos, y
lo implementará en la capa de datos de la aplicación, de acuerdo a las directrices generales expuestas
en este Apartado. Para ello se le presentará la información recopilada por los responsables del
proyecto en Itelazpi. Si fuera necesario, se celebrarán reuniones con los responsables de procesos
clave para el inventario (albergue, broadcast, transporte) con el objeto de acotar el alcance en cada
ámbito.
El corazón del sistema, y objetivo prioritario del GIA, es disponer de un inventario centralizado de
todos los subsistemas anteriormente referidos. Se piensa en un motor de base de datos, al cual
tengan acceso todos los sistemas o aplicaciones que requieran de información corporativa coordinada.
Tanto aquellas aplicaciones que se deriven de este proyecto, como otras ya existentes: Netcool,
Gestión de Incidencias, Bases de Datos y tablas de trabajo ofimáticas de cada área.
Se deberá definir inicialmente el modelo de datos, que deberá ser lo suficientemente flexible como
para incorporar nuevas tablas, relaciones y campos específicos por tecnología a lo largo del proyecto y
de su evolución posterior.
Itelazpi debe tener acceso totalmente libre a la BBDD, en los perfiles de administrador, para modificar
el modelo de datos según sus necesidades.
El inventario deberá soportar la integridad de los datos mantenidos, incluyendo accesos simultáneos
desde varias aplicaciones.
Independientemente de los métodos de interacción de nivel superior, deberá permitir consultas típicas
de procesos de BBDD, mediante queries, enlaces ODBCs o similares, de modo que ciertas tareas se
puedan automatizar y crear conexiones o enlaces sincronizados con ciertas aplicaciones ofimáticas de
usuarios. En particular es importante el disponer de medios eficaces para realizar
cargas/desactivaciones masivas de datos, etc, que agilicen ciertas actuaciones más allá del interface
genérico de usuario que se defina. También es fundamental disponer de canales de comunicación
con Netcool para la actualización del inventario, y con la aplicación de gestión de incidencias para
poder identificar elementos asociados a una incidencia.
27 de 66
Sobre este inventario deberán poder pivotar todas las aplicaciones corporativas que se desarrollen,
independientemente de que en el alcance de este proyecto nos centremos más en algunas áreas
concretas. En el siguiente esquema se describe sobre qué parte del inventario interactúa cada uno de
los procesos de la compañía afectados.
Infraestructura Red GV Fibra
-Arquetas, conductos, cables FO
-Infraestructura: acceso, caseta, torre…
-Elementos de Ocupación: racks, antenas
-Energía: líneas, grupos, cuadros….
-Sistemas tecnológicos Itelazpi
-Difusión, Transporte, TETRA, WiMAX,
INVENTARIO CENTROS
28 de 66
El Inventario se puede dividir en 4 apartados diferenciados:
- Infraestructuras: aquí se debe tomar el Centro, o emplazamiento, como la base de toda la
actividad de Itelazpi, y todo elemento físico o lógico debe poder estar relacionado a un
emplazamiento. Es importante reflejar todos sus datos de ubicación, acceso,
subinfraestructuras: casetas, torres, salas, racks, etc. Son fundamentales los datos de
patrimonio: titularidad, accesos, documentos de cesión, contratos eléctricos… Es de gran
utilidad que se disponga de capacidades GIS para mejorar la usabilidad de la herramienta en
el interface que se diseñe. Contiene elementos generales del centro: techos, extintores,
llaves de acceso, puertas, que son objeto de actuaciones periódicas.
- Elem. Ocupación: se trata de unos contenedores virtuales que tratan de medir la capacidad
de un elemento de infraestructura para albergar sistemas de telecomunicación. Las torres y
salas se dimensionarán para una estimación de antenas o racks que pueden soportar, y de
ahí desarrollar a medio plazo aplicaciones de asignación de espacio y reporting de ocupación
de centros. También se debe utilizar para reportar a financiero la ocupación y consumo de
los servicios albergados. También se considerarán elementos de ocupación los conductos
de telecomunicaciones del Gobierno vasco
- Energía: es un subsistema de soporte a todo el resto de la actividad de Itelazpi. Engloba
también los contratos de Iberdrola. Además de todos los componentes de suministro y
conversión eléctrica.
FINANCIERA
SSL
Medio Ambiente
ALBERGUE
OBRA CIVIL
ENERGIA
TRANSPORTE
LEGAL
Areas Negocio
Broadcast, TETRA, KZBZ
Infraestructuras
Energía
Elementos
Ocupación
Sistemas Tecnológicos
Centros Infr. De Centro Ocupación de centros
ERP Activos
Situación Patrimonial
Infr.
Elem
Inspecciones
Invent sistemas telecom
Invent sistemas txte
Invent sistemas energía
SISTEMAS TI
Invent TI
INVENTARIO
29 de 66
- Subsistemas de telecomunicaciones: engloba los elementos de transporte, broadcast, TETRA,
WiMAX, etc. Constan habitualmente de múltiples subcomponentes, y cada uno puede dar
servicio a un determinado cliente.
Al tratarse el centro de radiocomunicaciones el eje de la actividad del Itelazpi, el inventario parte de
este elemento como clave principal, y a partir de ahí se puede establecer una lógica jerárquica de
activos. A continuación se presentan unos ejemplos de jerarquías de ubicaciones de elementos:
Centro -> Torre -> Antena
Centro -> Caseta -> Sala -> Rack -> Transmisor TDT -> Módulo de alimentación
Segmento de canalización FO -> Conducto -> Cable FO
No obstante, esta jerarquía no puede ser rígida, ya que, p.ej., puede haber sistemas de
telecomunicación albergados directamente en una sala, sin estar ubicados dentro de un rack.
4.2. FUNCIONALIDADES DE GESTIÓN DE INVENTARIO DE RED.
Además del modelo puro de datos descrito en el anterior apartado, se considera fundamental el
establecimiento de una capa o lógica de negocio por encima de la de datos, que recoja todas las
relaciones entre elementos y los cálculos asociados que puedan ser necesarios.
Dada la naturaleza de los servicios de telecomunicaciones, el Inventario debe poder recoger los
servicios de telecomunicaciones que se prestan a clientes, y asociarlo a elementos físicos, uno o
varios. Por ejemplo:
• Servicio de TDT Multiplex de EiTB emisión de Ganeta. Elemento principal: transmisor de TDT de
Ganeta. Otros elementos relacionados: cuadro eléctrico de alterna, transformador, grupo
electrógeno, OMSN de transporte de Ganeta… etc.
De la misma manera, para organizar de manera adecuada ciertos activos de telecomunicaciones
puede ser necesario crear unidades lógicas. Por ejemplo:
• Un radioenlace Oiz – Ganeta es una entidad “lógica” asociada a dos centros, que tiene
relacionados dos subcomponentes: radioenlace de Oiz-Ganeta (equipo de Oiz), y de Ganeta-Oiz
(equipo de Ganeta). Independientemente del mayor desglose posterior de subcomponentes.
30 de 66
Otra unidad lógica clara es la relacionada con equipo de transmisión en un centro concreto. Este
equipo de transmisión del centro de Ganeta, p.ej., es un elemento lógico al que posteriormente hay
que relacionarle unos canales de transmisión, una potencia, un índice de disponiblidad según el SLA
del servicio que soporta, o un nº de preventivos anuales determinado. Sin embargo, el transmisor
físico que realiza esta función puede ser ahora un modelo Rohde xxx, y en caso de considerarse
necesario, sustituirse por otro equipo de otro fabricante, que tiene unos submódulos totalmente
diferentes. En suma, el componente lógico es el transmisor de TDT de Ganeta de los canales 61 y 63,
y el componente físico, con el que está relacionado, es un Transmisor Rohde con otros parámetros
técnicos y módulos determinados.
Por todo ello, se considera fundamental que la arquitectura de datos y la lógica de negocio sean lo
suficientemente flexibles como para crear de una manera dinámica estas relaciones entre elementos
físicos y elementos lógicos de red. Por supuesto, que pueda reflejar las subdependencias entre
componentes, pero también relaciones cruzadas.
Asimismo, cada uno de los componentes del inventario tendrá una serie de atributos o campos,
algunos de los cuales serán genéricos y aplicables a todos ellos. Sin embargo, las especificidades de
cada tecnología hacen que sea necesario añadir para cada tipo de componente una serie de campos o
parámetros específicos. Por ello el sistema deberá aportar la flexibilidad para esta definición de
campos. En la medida de lo posible, ciertos perfiles de administrador deberían permitir estas acciones
a responsables de procesos o de cada una de las tecnologías.
En cuanto a gestión de capacidades, se requiere unas mínimas funcionalidades, sobre todo en cuanto
a gestión de ocupación de espacios en los centros. A cada torre y caseta se le asignará una capacidad
teórica, y su capacidad se dividirá en espacios. En función de la ocupación de esos espacios se podrán
asignar nuevos espacios libres a nuevas ocupaciones, u obtener estadísticas de nivel de saturación de
los centros. Otras posibles capacidades gestionadas son la de consumo eléctrico en un centro, o la de
capacidad de transmisión de la red de transporte. La herramienta debe estar diseñada para poder
desarrollar estas gestiones en el futuro.
Por último, un aspecto importante debe ser la posibilidad de establecer un flujo de trabajo básico, en
el que a cada tipo de activo se le asignen responsables de ejecución de cambios y su validación. Por
tanto, deberá existir un atributo de activos que es su estado de validación.
31 de 66
4.3. FUNCIONALIDADES DE GESTIÓN DOCUMENTAL.
La aplicación de inventario deberá gestionar la documentación asociada a los activos, listada en el
apartado de descripción de 3.5 Tablas y bases de datos ofimáticas. Se deberán presentar listados de
acceso a documentos por las clasificaciones más habituales, pudiéndose además poder realizar
búsquedas según diferentes criterios. No se piensa tanto en un sistema de almacenamiento
documental, en base de datos, como en un acceso ordenado a documentos que están albergados en
sistemas convencionales como sistemas de archivos de ficheros. No obstante, tras el análisis inicial, el
diseño puede incluir ciertos tipos de documentación como componentes de la base de datos. La
documentación se almacenará en unas determinadas carpetas de red, y la aplicación relacionará a los
activos con su ubicación.
Se considera como un importante valor añadido que la consulta o apertura de documentación
asociada se puede hacer de modo embebido en el mismo portal, de manera que se mantenga una
sensación de herramienta completa para el usuario. De manera que, al seleccionar un determinado
activo, se podrá previsualizar en la aplicación la documentación seleccionada, por lo menos aquella
existente en los tipos de documentos más habituales: MS Office, imágenes, PDF, Autocad.
El licitador deberá describir el método, arquitectura y funcionalidades de la gestión documental
ofrecida. Asimismo, el adjudicatario en la fase de integración colaborará en la detección de los
ficheros informatizados, definir la reorganización de carpetas más idónea, realizar el traspaso de
documentos, y proponer los métodos de acceso más prácticos a la documentación.
Resulta de especial utilidad para Itelazpi la integración de inventario con la planimetría en AutoCad de
las plantas y alzados de torre. Idealmente, esta planimetría debería ser un medio de navegación más,
en las siguientes maneras:
- En el área de geolocalización o en los listados de centros, al seleccionar un centro, además
de poder acceder a las páginas de listados de elementos del centro, o a las fotografías, se
pretende poder mostrar la planimetría de plantas y torres, y visualizar los elementos del
centro.
- Una vez visualizada dentro de la herramienta la planimetría, se pretende poder seleccionar
un elemento, dentro de la planimetría: antenas en torre, racks, equipos…
- Al seleccionar un elemento en los listados no gráficos, y acceder a la documentación
asociada: fotos, as-builts, etc, uno de los accesos debe poder mostrar el plano de planta o
torre, y resaltar la ubicación del elemento.
Itelazpi dispone ya de esta planimetría de centros, con identificativos para cada espacio ocupado,
tanto en planta como en torre. A continuación se muestra un ejemplo de dicha planimetría, disponible
en formato AutoCad, y que contiene distintas capas por cada tipo de espacio o elemento.
32 de 66
33 de 66
Para ello, el adjudicatario deberá examinar conjuntamente con Itelazpi el formato de estos ficheros, y
diseñar el máximo nivel posible de integración con el inventario. Asimismo, se propondrán los cambios
necesarios en los formatos de estos ficheros para conseguir toda la integración potencial con los datos
existentes. Posteriormente se modificará una muestra de las planimetrías, escogiendo un centro tipo,
y se diseñará la herramienta con la integración descrita.
El licitador describirá la propuesta de integración para esta planimetría. No entra dentro del alcance
del contrato la carga o modificación inicial en toda la documentación existente, tarea que será
responsabilidad de Itelazpi y será desarrollada paulatinamente.
4.4. FUNCIONALIDADES DE REPORTING/INFORMES
La aplicación deberá presentar una serie de informes predefinidos, así como posibilitar la generación
de informes a medida, según necesidad, de una manera lo más sencilla e intuitiva posible. El
adjudicatario colaborará con Itelazpi en la definición de los informes predefinidos que se desarrollarán
e implementarán en la aplicación. De modo orientativo, como ejemplo, se indican algunos informes,
junto con los indicadores que deben contener:
• Nº de centros gestionados por Itelazpi
• Nº de centros con equipamiento gestionado por Itelazpi
• Listado de centros por categoría
• Listado de centros por provincia
• Grado de ocupación de torre y caseta de los centros C1
• Nº de transmisores por subsistema (broadcast TDT, FM, WiMAX, TETRA…)
• Listado de grupos electrógenos en centros C2
• Listado de contratos de Iberdrola
• …….
Los informes deben poder exportarse a ficheros externos, en formatos MS Office o PDF Acrobat.
4.5. INTEGRACIÓN CON FICHEROS Y BASES DE DATOS OFIMÁTICAS DE ITELAZPI
El adjudicatario realizará la definición conjunta con Itelazpi de los activos a inventariar y el detalle de
los elementos y atributos que se deben volcar en la aplicación. Para ello analizará los repositorios de
información existentes en la casa, y realizará la primera carga masiva de información, en bloque, en la
nueva aplicación.
34 de 66
Una vez en marcha el sistema, en producción, los usuarios del sistema podrán seguir utilizando sus
ficheros locales, en los que es posible que añadan información que no es relevante por el inventario:
datos de configuración, rendimiento, etc., que no estén contemplados en el nuevo sistema. Aquellos
que lo realicen, deberán poder integrar estos documentos con el GIA. Esta necesidad surgirá en
aquellos procesos operativos que manejan altas cantidades de información de configuración:
broadcast, transporte, obras..
La interacción de estos ficheros será unidireccional GIA -> fichero. Los ficheros actualizarán su
información procedente del GIA para obtener datos de centro, elemento, etc. La actualización de
datos de inventario será siempre única y la realizará cada proceso en la aplicación suministrada GIA.
El adjudicatario realizará el análisis e implantará la interacción entre el GIA y los ficheros ofimáticos de
estos procesos para que puedan seguir operando de la misma manera en la gestión de sus datos de
configuración.
4.6. INTEGRACIÓN CON OTRAS APLICACIONES DE ITELAZPI
Se requiere la integración del GIA con la aplicación Netcool, al objeto de que la CMDB de Netcool se
actualice a partir de los datos del GIA. Para ello el adjudicatario analizará la arquitectura de esta
CMDB y propondrá el método de interconexión más adecuado. El adjudicatario diseñará e
implementará, de acuerdo al método propuesto en su oferta, esta interconexión, que en todo caso
será siempre unidireccional GIA –> CMDB Netcool.
Netcool deberá disponer de esta manera de forma permanentemente actualizada de toda la
información que precisa para el enriquecimiento de los eventos que gestiona: centros, su nombre y
código, categoría, elementos gestionados por tecnología, su dir. IP identificativa, servicio asociado,
etc.
Otra integración requerida es la relacionada con la aplicación de gestión de incidencias MS Service
Manager. De igual manera que en el anterior caso, se deberá realizar el análisis conjunto de la
arquitectura de datos en SM, identificar las tablas y atributos que deben ser actualizados desde el
GIA, y finalmente diseñar e implementar el método de comunicación propuesto en la oferta. En este
caso, la información fundamental procedente del GIA que debe actualizarse en el SM es la referente a
centros, su categoría, y, en el CI equipos, ahora vacío y sin uso en el SM, completarlo en el nivel más
alto (equipo, sin subjerarquías de módulos, etc). De este modo, el CAU podrá completar la
información de las incidencias con el equipo afectado, en los casos en los que sea aplicable. Además
de una primera carga inicial, la información deberá poder ser actualizada periódicamente. Al igual que
35 de 66
en el caso anterior, las altas, eliminaciones, modificaciones de atributos, etc de elementos, deberán
ser automáticamente modificadas en el SM.
Por último, el inventario deberá integrarse con el ERP corporativo RPS, a nivel de contabilidad, ya que
en RPS existen asientos contables por activo. El detalle y nivel de integración deberá ser acordado con
el adjudicatario en la fase de diseño. Como en los casos anteriores, el ERP deberá poder adquirir la
información de activos para sus funciones internas.
A día de hoy, ITELAZPI cuenta con una solución de portal Intranet/Extranet basada en MS Sharepoint,
a través de la cual ha desarrollado una estrategia de colaboración con sus grupos de interés:
• Portal Intranet
• Portales Extranet:
- Portal del Cliente
- Portal del Proveedor
- Portal del Instalador de Comunicaciones
- Portal del Accionista
La aplicación deberá poder integrarse con los portales de Intranet y extranet de Itelazpi. El licitador
presentará la estrategia de integración más adecuada. El adjudicatario debería proveer los
mecanismos necesarios para que dicha integración se pudiera realizar de la manera más eficiente.
4.7. INTEGRACIÓN CON LA APLICACIÓN DE MANTENIMIENTO
La aplicación de inventario deberá integrarse estrechamente con la aplicación de mantenimiento
suministrada, ya que ambos forman parte del proyecto GIA.
En este caso se debe procurar una integración bidireccional. Un cambio en un activo en el inventario
(alta, baja) se debe reflejar en la aplicación de mantenimiento, de cara a poderle asignar tareas
preventivas o correctivas. Del mismo modo, si un determinado activo ha sido objeto de una tarea de
mantenimiento que supone un cambio en los atributos del activo (p.ej. cambio de ubicación), esta
modificación debe reflejarse en el inventario.
El licitador deberá explicitar en su oferta el detalle y nivel de la integración que conseguirá entre
ambos subsistemas, así como las herramientas técnicas que implantará para su consecución.
36 de 66
4.8. REQUISITOS DE CAPACIDAD Y ESCALABILIDAD
La aplicación deberá ser capaz de abarcar la volumetría de activos estimada, según el listado del
Apartado de Descripción de los Activos, sin ninguna merma apreciable en rendimiento y
navegabilidad. Se indicará el volumen máximo de activos soportado por la aplicación para un
rendimiento apropiado, según los requerimientos de hardware especificados.
No deberán existir limitaciones prácticas por nº de licencias de usuarios nominales o concurrentes.
El sistema se debe dimensionar para un acceso concurrente de al menos 15 usuarios. Se indicará el
nº máximo de usuarios concurrentes para los que se garantiza un rendimiento apropiado.
Itelazpi dispondrá de la infraestructura hardware (servidores, red, PCs de usuarios..) y software de
soporte (licencias MS de SO, bases de datos, SharePoint…) para la implantación de la herramienta. El
licitador definirá explícitamente los requisitos Hardware y software precisos, tanto en los servidores de
la aplicación como en los clientes de acceso.
4.9. REQUISITOS DE FIABILIDAD Y RENDIMIENTO
La aplicación será totalmente robusta y resistente a fallos, excepciones u otros errores, volviendo en
estos casos automáticamente a un paso anterior tras la emisión del mensaje descriptor del error.
Deberá incorporar todas aquellas funcionalidades conducentes a minimizar la introducción errónea de
datos en cada punto de interacción con el usuario, en función del contexto del dato introducido,
mediante el formato de datos requerido, valores máx/mínimos, menús desplegables con las opciones
válidas o listado de elementos existentes, etc.
Dentro del plan de pruebas que se plantee durante la puesta en marcha de la aplicación, se deberán
realizar pruebas específicas de rendimiento para los accesos en red en condiciones reales de volumen.
El acceso previsto es en modo de red de área local, y el plan de pruebas de rendimiento se realizará
en este entorno. No obstante, se deberá contemplar el acceso en modo Internet/Extranet a ciertas
páginas de visualización y resumen de activos, así como indicadores de negocio.
37 de 66
4.10. REQUISITOS DE ADMINISTRACIÓN Y ACCESO
La aplicación propuesta deberá estar concebida, implantada y administrada de acuerdo a los
estándares de seguridad (ISO 27001, etc..) y de acuerdo a la legalidad aplicable (LOPD, etc..), de tal
manera que se garantice la confidencialidad, integridad, disponibilidad y trazabilidad de la información
procesada. ITELAZPI se reservará el derecho de establecer cláusulas de confidencialidad con el
adjudicatario.
Se deberá habilitar un mecanismo de integración con el sistema de directorio de ITELAZPI (en este
caso, Active Directory), que permita la autenticación de usuarios Intranet/Extranet/Internet haciendo
uso de las mismas credenciales de acceso, que ITELAZPI utiliza para el acceso al resto de los sistemas
propios.
Se deberán poder crear roles, a los cuales adherir las cuentas de acceso en función de los diferentes
perfiles deseados. Se deberá poder asignar niveles de permiso (consulta, descarga, modificación,
creación de activos…) para cada categoría de activos.
Los usuarios con perfil administrador tendrán al menos la capacidad de:
• Creación/modificación/eliminación (gestión) de roles y permisos para cada rol y tipo de activos
• Gestión de tipos de activos físicos y lógicos
• Gestión de relaciones entre activos
4.11. REQUISITOS DE PRESENTACIÓN
El acceso a la aplicación, con cualquiera de los roles de acceso, será un interface web basado en IE.
En función del rol de la cuenta de acceso, se presentarán solo aquellas pantallas, opciones y menús o
funcionalidades a las cuales tiene acceso.
Las páginas para acceso y las de administración de contenido, deberán poseer una interfaz gráfica lo
suficientemente enriquecida/automatizada como para garantizar un uso eficiente de la aplicación. Se
describirán las capacidades gráficas de la propuesta realizada. Se describirán también todas aquellas
funcionalidades orientadas a mejorar el tránsito entre pantallas, despliegue de menús y opciones, así
como a mejorar la facilidad de introducción/modificación de activos y sus atributos.
La lógica de navegación entre activos responderá a la arquitectura jerárquica Centro -> Equipamiento
-> Módulos de equipo. Sin embargo, la transición lógica de los usuarios requerirá al menos 4 vías de
búsqueda de la consulta deseada. El adjudicatario colaborará con Itelazpi en la definición de las
38 de 66
transiciones, filtros y búsquedas necesarias. Como ejemplo, se describen algunos de los flujos
posibles:
Sitio de inicio:
• Seleccionar Centro(s) (por provincia, categoría, tipo de equipamiento contenido…)
• Seleccionar Centros por geolocalización
• Seleccionar Equipamientos (por centro, tipo…)
• Seleccionar Equipamientos/elementos relacionados con el objeto seleccionado.
• Seleccionar elementos geoespacialmente
En una primera fase de diseño, se acordará con el adjudicatario el mapa de navegación por la
aplicación, los interfaces de acceso, los enlaces entre pantallas, en definitiva el diseño del interface de
presentación. Todo ello partiendo de la propuesta del adjudicatario en su oferta, con las diferentes
opciones y posibilidades aportadas, a partir de su evaluación de las necesidades expresadas en este
pliego y de su experiencia anterior en proyectos similares.
Se debe partir de que el personal de Itelazpi está habituado al uso de la Intranet propia basada en
SharePoint, con los elementos habituales: Menu de navegación Global de sitio, Menu de navegación
Rápida, Buscador, Miga de Pan, Bibliotecas, Listas, metadatos, vistas de hoja de datos …
Las funcionalidades estándar de SharePoint se deberán complementar con todos aquellos desarrollos
que sean precisos, orientados a mejorar selecciones/mostrar datos múltiples de elementos,
previsualizaciones, navegación geoespacial, entradas/modificaciones masivas de datos, visualizaciones
compactas, etc. Se entiende que la capa de presentación se debe integrar con las actuales
Intranet/Extranet basadas en ShP, pero esta capa debe crearse desde su concepción como un
elemento independiente de la aplicación de portal, y debe incorporar todas las ventajas disponibles en
la tecnología de desarrollo que se utilice.
Requiere especial importancia la pantalla de selección geoespacial que permita acceder a los datos de
un centro o conjunto de centros, a partir de su ubicación en un mapa cartográfico o vista satélite.
Ante la selección de un centro o centros, se debe disponer de un menú seleccionable, que permita:
• Información resumida de centro
• Enlace a información patrimonial del centro
• Enlace a elementos instalados en el centro.
• Previsualización de documentos del centro
39 de 66
Se debe disponer de la posibilidad en un menú asociado a esta pantalla geoespacial, de acceder de
manera similar a información por tipo de elemento: Radioenlaces, Nodos de transporte, Transmisores
TDT, FM, BTS TETRA, Grupos electrógenos, Mapas de cobertura por servicio, etc. En este caso, el
menú desplegable posibilitará el acceso a la información del elemento, un enlace a todos los
elementos relacionados, previsualización de documentos relacionados, etc.
La aplicación se deberá integrar tanto en el entorno Intranet como Extranet de Itelazpi, basado en la
actualidad en MS SharePoint.
La aplicación suministrada permitirá en el futuro un interface de usuario adaptado a movilidad. Como
mejora, el licitador podrá proponer dentro del alcance del proyecto la implantación de esta capa
orientada a movilidad. En este caso, la tecnología móvil actual de Itelazpi está basada en el sistema
operativo Android v4. En cualquier caso, la solución debe ser compatible para uso en movilidad con
dispositivos móviles basados en los principales sistemas operativos (ANDROID, IOS y WINDOWS
PHONE). Se describirá el alcance y arquitectura de esta solución en caso de ser ofertada.
También como mejora se podrá proponer una versión bilingüe Español-Euskara, que añada el euskera
como opción para la capa de presentación de la aplicación. En este caso el adjudicatario será el
responsable de una correcta correspondencia entre ambos idiomas de toda la capa de presentación.
4.12. REQUISITOS TECNOLÓGICOS.
La aplicación se deberá integrar en el entorno tecnológico de Itelazpi, que en cuanto a software se
centra sobre todo en entorno Microsoft:
• PCs cliente: S.O. MS Windows 7 Enterprise, SP1. MS Office 2010 (Excel, Access…), MS IE 9
(también se utilizan Firefox y Chrome, por lo que la solución deberá ser compatible con todos
estos navegadores).
• HW típico de los PC clientes: Lenovo ThinkPad T430. Intel Core I53230M 2,60 Ghz, S.O. 32
bits, 2 Gb RAM. Adaptador de pantalla Intel HD Graphics 4000. No se disponen de otras tarjetas
de aceleración gráfica.
• Servidores HP. S.O MS Windows Server, Datacenter 2012.
• El entorno de ejecución estará basado en infraestructura virtualizada sobre hypervisores
VMWARE vSPHERE 5.
• MS SQL Server 2012.
• MS SharePoint 2013 Enterprise.
40 de 66
La aplicación suministrada se apoyará en el entorno tecnológico de Itelazpi. La capa de datos se
deberá basar preferentemente en SQL Server. Itelazpi aportará una infraestructura de base de datos
basada en MS SQL Server 2012 Standard. En caso que la solución soporte múltiples sistemas de base
de datos, se deberá utilizar la plataforma SQL Server provista por Itelazpi. En caso que la solución
propuesta esté basada en otro sistema de base de datos, el adjudicatario deberá aportar la
correspondiente licencia del producto (para los entornos de integración/producción), la instalación de
los diferentes entornos y su mantenimiento hasta el 31 Diciembre del 2016.
La capa de negocio y presentación, en aquellos aspectos que requiera de un desarrollo a medida, se
basará en entorno de programación abierto .NET o similar, que facilite la integración con los portales
de Itelazpi, y la evolución posterior de la aplicación mediante la documentación del código abierta de
programación, y la compilación de la aplicación por el propio personal de sistemas de Itelazpi y otros
proveedores futuros. Se deberán presentar las ventajas de la tecnología de desarrollo propuesta. La
capa de presentación deberá ser compatible para su integración con el producto SharePoint,
integrando en éste como webparts aquellos desarrollos realizados si fuera necesario.
El licitador deberá exponer los requisitos HW, SW y de capacidad de los servidores y puestos de
usuario que se requieren para la solución ofertada.
Se aportarán entornos de prueba y producción.
4.13. FORMACIÓN Y DOCUMENTACIÓN
Los licitantes propondrán un plan de formación de la aplicación, así como para la administración de
contenido. ITELAZPI identificará quienes deberán recibir la formación de usuario /Administración de
Contenido y Administración del Sistema.
Además de la formación inicial, se deberán plantear formaciones periódicas, con una cadencia no
mayor de 1 año. Las revisiones formativas serán obligatorias ante cualquier cambio mayor de la
aplicación (nueva versión, etc…).
El adjudicatario deberá aportar la documentación asociada a la aplicación, como documento de
entrega final del proyecto. Así mismo, ante cualquier modificación de la aplicación, el adjudicatario
deberá enviar la correspondiente actualización.
Dentro de la documentación del proyecto, se presentarán tres subdocumentos de diseño de cada capa
de la aplicación: datos, empresarial y presentación. Se indicará cómo se ha resuelta cada uno de los
aspectos y subapartados de cada capa, con parametrización/personalización de herramientas o
41 de 66
desarrollo. Se entregará el código fuente documentado y con descripciones de todas las partes
diferenciadas de código (variables, objetos, funciones….).
En las posibles acciones de integración, que impliquen a terceros, el adjudicatario entregará la
documentación requerida por el integrador (arquitectura técnica, arquitectura de la información,
modelo de datos, especificaciones de comunicación (Web Services, XML, etc….), código modificado o
añadido.
4.14. MANTENIMIENTO DE LA APLICACIÓN.
Dentro del suministro de la herramienta de inventario, no se contempla el servicio de mantenimiento
tras la fase de entrega y aceptación del aplicativo. Sí se debe incluir, sin embargo, la garantía, coste
de licencias y actualizaciones de versión en los dos ejercicios siguientes a la entrega del proyecto
(máximo hasta 31 de Diciembre de 2016).
42 de 66
5. APLICACIÓN DE MANTENIMIENTO.
El adjudicatario deberá suministrar y parametrizar conforme a los requerimientos de Itelazpi, una
aplicación de Mantenimiento de los activos gestionados por la compañía, que deberá integrarse al
máximo con el inventario desplegado, descrito en el apartado anterior.
5.1. FUNCIONALIDADES GENERALES DE GESTIÓN DE MANTENIMIENTO DE RED.
En esta aplicación dentro del proyecto GIS, se deben soportar las actividades de Itelazpi en cuanto a
mantenimiento. El apartado más claro es el seguimiento de mantenimientos preventivos, aunque
también otras tareas correctivas o no planificadas. También, en un mayor detalle, se pretende poder
realizar el seguimiento de la logística del material inventariado, con el objeto de poder trazar los
movimientos de material. Esta funcionalidad puede complementarse con la gestión de las órdenes de
trabajo que van asociadas a los movimientos de material o cambios de configuración.
En todos estos aspectos de mantenimiento, existe una documentación asociada, que debe poder ser
visualizada, y ordenada de una manera intuitiva para los usuarios. Estos usuarios son prácticamente
todas las áreas de la empresa, e incluso las contratas de mantenimiento de los procesos operativos
deben poder acceder a ella, ya que participarán en la operativa diaria y mantenimiento de la
información de la aplicación.
En los siguientes Apartados se detallan las funcionalidades de mantenimiento preventivo y correctivo
requeridas.
5.2. FUNCIONALIDADES DE MANTENIMIENTO PREVENTIVO.
Se pretende la implantación de una herramienta de gestión de todas las tareas o mantenimientos
preventivos de los activos de la compañía. Habitualmente, cada proceso es responsable de un área de
soporte o tecnológico, y existe un contrato de mantenimiento con una compañía externa que se
encarga de todas las actuaciones de 1er nivel, tanto las preventivas como las correctivas. Cada
actuación de preventivo en un elemento supone, casi siempre, un desplazamiento al centro, aunque
ciertas tareas se realizan en remoto. Además, cada preventivo se desglosa en una serie de tareas:
subelementos a comprobar, parámetro que medir, etc. Las tareas y frecuencias de ejecución de
preventivos pueden ser variables en función del tipo de elemento, la importancia del centro, u otro
factor. A continuación se presenta un ejemplo de tareas y su planificación en un contrato concreto.
43 de 66
DESCRIPCIÓN TAREAS MANTENIMIENTO
FRE
CU
EN
CIA
C1
FRE
CU
EN
CIA
C2
FRE
CU
EN
CIA
C3
FRE
CU
EN
CIA
C4
1. RADIO-ENLACES DE ALTA Y BAJA CAPACIDAD. 1.1. ELEMENTOS EN TORRE.
Comprobar estado general de las antenas, sujeción de las mismas, reapriete, tomas de tierra (antenas mayores de 1,2m). 1 1 1
Comprobar estado general de herrajes de antena, oxidación, apriete, etc. 1 1 1
Comprobar el estado general de las guías de onda ó cables de bajada de antena, grapas de sujeción, recorrido, etc. 1 1 1
Comprobar estanqueidad del acceso al centro de los cables y guías en el pasamuros. 1 1 1
Comprobar estado de tejadillos de protección contra el hielo. 1 1 1.2. PRESURIZACIÓN.
Comprobar correcto funcionamiento del presurizador, presión de aire, conexión de red, limpieza general, etc. 12 6
Comprobación de ausencia de fugas de aire en todos los circuitos de usuarios. 12 6
1.3. EQUIPOS EN INTERIOR.
Comprobación del estado de las conexiones de alimentación, reapriete, limpieza y correcto rotulado de las mismas en cuadro y en la manguera. 1 1 1
Comprobación de correcta puesta a tierra del bastidor. 1 1 1
Comprobación del correcto rotulado del servicio y frecuencias de Tx y Rx. 1 1 1
Comprobación del correcto estado de los elementos de ventilación del equipo. 12 6
1.4. MEDIDAS Y COMPROBACIONES.
Medida de campo recibido con ATPC excluido (Medido con PC). Comparar nivel con el Nominal e intervenir en caso de ser necesario. 12 6 1
Back-up de configuración del equipo. 12 6
44 de 66
En función de lo descrito anteriormente, y para poder cumplir el objetivo de planificar, medir y
documentar adecuadamente los mantenimientos preventivos de Itelazpi, la aplicación deberá poder
establecer las siguientes funciones:
• Gestión de contratos de mantenimiento, asociándoles elementos del inventario de activos por
tipos, y procesos internos que lo gestionan y contratas de mantenimiento asociadas al contrato.
• Realizar, por cada contrato, activo o tipo de activo, una planificación anual periódica de los
preventivos que se deben realizar por cada elemento, o tipo de elemento. Para cada tipo de
elemento o subgrupos (p.ej. transmisores de TDT de los centros C1) se deberá poder
especificar una frecuencia distinta, así como un Plan de preventivo (tareas que debe incluir)
especifico. Las asignaciones de Planes preventivos, y planificaciones deben ser amigables y
poder realizarse en bloques agregados, según filtros o búsquedas por metadatos del inventario,
para facilitar la labor de organización. Las fechas de ejecución posibles serán flexibles, dando
rangos de ejecución. Un perfil de administrador de mantenimientos será el encargado de crear
y supervisar los contratos, planes de mantenimiento, las asignaciones de ejecutores y las
planificaciones de ejecución. También tendrá una vista general del cumplimiento de la
planificación en cuanto a ejecución de preventivos.
• A cada preventivo se le asignará un responsable (normalmente la contrata de 1er nivel
asignada) que debe realizarlo. El ejecutor deberá poder marcar previamente la fecha prevista
para la actividad, Una vez realizado, el ejecutor deberá poder marcarla como realizada,
debiendo indicarlas personas que han intervenido, la fecha real, hacer un check en los campos
principales indicando la correcta ejecución, y observaciones. Deberá poder asociar documentos
o plantillas rellenadas, que se adjuntarán como documentación asociada al replanteo.
Asimismo, se deberán poder adjuntar otras documentaciones asociadas (fotos). Los checks
deberán ser fáciles de rellenar, conteniendo el valor Correcto (ok) para facilitar la labor del
operario y que solo tenga que anotar las situaciones anómalas.
• La aplicación deberá presentar a cada ejecutor, cuando se registre con su cuenta, una vista
general del estado de los mantenimientos asignados, el estado de la evolución de la ejecución y
avisos de aquellos mantenimientos fuera de plazo. Cada ejecutor deberá completar los checks
de su preventivo, los datos de ejecución, completar observaciones o registrar inconformidades.
En general el proceso de rellenar la ficha de preventivo debe suponer un intervalo de tiempo
corto para el técnico o contrata y no ser complicado.
• La aplicación debe poder programar flujos de trabajo relacionando activos participantes en cada
actividad, ejecutores, validadores, etc. Todo ello pudiendo relacionarlo con otros elementos
pertenecientes al ERP corporativo de Itelazpi: pedidos, facturas, etc.
• Aunque inicialmente una ficha como documento adjunto al preventivo puede ser suficiente, en
algún ámbito será necesario completar checks que serán campos en la base de datos, y datos
de medidas de campo realizados en el preventivo, que deben ser tratables para observar
evoluciones en el tiempo. Se deberán poder asociar valores de parámetros medidos en el
mantenimiento, y compararlos con umbrales de máximo/mínimo, y poder establecer avisos
visuales ante valores fuera de umbral. En cualquier caso, siempre se debe buscar la agilidad al
45 de 66
completar datos. P.ej. poder dar por completos varios preventivos simultáneamente, que esto
marque como realizados todos los checks asociados y solo se marquen los campos que han
supuesto una anormalidad.
• Se deberán presentar informes de cumplimiento de preventivos generales, por contrato,
proceso o área, tipo de elemento. También se definirán los indicadores más significativos y se
representarán en los informes correspondientes de cuadro de mando.
El licitador detallará todas las prestaciones y posibilidades de la herramienta en cuanto a
mantenimientos preventivos, y cómo se propone cubrir las necesidades aquí expresadas. Además
describirá todas las funcionalidades añadidas que proporciona la herramienta, que serán valoradas en
la evaluación de la solución.
El adjudicatario deberá definir conjuntamente con Itelazpi en una fase inicial del proyecto el alcance
de la parametrización necesaria, así como las particularizaciones acordadas. Asimismo se acordará el
calendario de la implantación, siempre dentro de los plazos comprometidos en la oferta.
5.3. FUNCIONALIDADES DE MANTENIMIENTO CORRECTIVO.
El flujo de gestión de correctivos en Itelazpi se inicia en el CAU como receptor de incidencias, cuenta
con el soporte de técnicos especialistas y de guardia de Itelazpi, y con contratas de mantenimiento de
1er nivel. El CAU es el responsable de la recepción de incidencias, monitorización remota de la red
(Netcool) para apertura de incidencias proactivas, y del inicio, seguimiento y cierre del flujo de
resolución de la incidencia.
Para ello aporta su propia herramienta de gestión de incidencias, en la actualidad se trata de Microsoft
System Center Service Manager 2012. En esta herramienta se recogen actualmente líneas de
progreso, pero no se generan órdenes de trabajo a contratas, tan solo se asignan resolutores y se
contacta con ellos para la notificación, seguimiento y cierre.
La herramienta de mantenimiento ofertada debe aportar las siguientes funcionalidades de
mantenimiento correctivo:
• Capacidades de gestión de incidencias. Se deben poder registrar, modificar, cambiar estados de
incidencias del servicio, reportadas por llamadas de clientes o monitorización de red, de modo
que en un futuro la aplicación suministrada pudiera sustituir al SM actualmente utilizado.
• Posibilidad de integración con la herramienta actual SM, para descargar las incidencias
registradas actualmente.
46 de 66
• Generación de tareas correctivas, asignadas a la empresa que debe realizar la actuación.
Cuando incluye desplazamiento, se debe poder registrar el personal desplazado, empresa
designada, material reparado o sustituido si ha sido preciso, su código de inventario, actualizar
la información sobre el movimiento de material en el inventario, hora de comienzo y finalización
del parte, y otros datos que puedan ser necesarios para el completo seguimiento del correctivo.
• La asignación a una tarea de: elementos del inventario, ejecutores, etc debe poder realizarse
de una manera intuitiva y fácil, con menús desplegables o subventanas que faciliten la labor.
• Se debe poder establecer un flujo de trabajo asociado a cada tarea correctiva, en la que cada
uno de los pasos o evoluciones de la tarea sea asignado o tenga que ser validado por un
responsable.
El objeto final de este apartado, sería la identificación con códigos propios de Itelazpi y etiquetado de
todos los elementos, con códigos de barras o similares en campo. Poder realizar una trazabilidad de la
vida de los componentes, detallando también los códigos de serie del fabricante en aquellos ámbitos
en los que existe. De esta manera se potenciará la mejora en el control de logística del material, y se
independizará en mayor medida entre equipamientos “lógicos” que dan servicio en un centro, y los
componentes físicos que lo soportan y que pueden tener más movilidad. Se deberán añadir nuevos
emplazamientos como almacenes o fábricas de suministradores.
La intención es poder asociar órdenes de trabajo a contratas o personal, en general, encargados de la
ejecución de estos movimientos de material, y poder realizar su trazabilidad.
Esta funcionalidad de órdenes de trabajo se podrá hacer extensible a otras actuaciones en la red que
no impliquen movimiento de material, permitiendo trazabilidad también de la actividad del personal y
contratas de mantenimiento.
5.4. FUNCIONALIDADES DE GESTIÓN DE PROCESOS Y DEFINICION DE WORKFLOWS.
La aplicación dispondrá de una herramienta que permita generar procesos y flujos de trabajo sobre
cualquier entidad y proceso existente en la aplicación. Los procesos definidos con esta herramienta de
workflow deberán ser capaces de:
• Ser definidos de forma gráfica sin con diagramas de flujo.
• Los flujos de procesos estarán formados por tareas asignables a usuarios y/o roles.
• Abrir cualquier pantalla de la aplicación de mantenimiento.
• Detectar cualquier cambio en los datos de la aplicación de mantenimiento y actuar lanzando un
proceso.
• Enviar mensajes internos y de email a los usuarios de la aplicación.
47 de 66
• Recoger y enviar ficheros integrándolo con el archivo documental.
• Registrar y generar cualquier dato de la aplicación.
• Hacer llamadas a procesos externos de la aplicación, tanto de la aplicación del inventario como
del ERP.
5.5. FUNCIONALIDADES DE GESTIÓN DOCUMENTAL.
Al igual que en la aplicación de inventario, se debe poder asociar documentación de mantenimiento a
cada elementos de la aplicación. Como ejemplos citaremos los siguientes:
• Acceso a la documentación del inventario de activos de la red, asociados a un correctivo.
• Manuales con los procedimientos, plantillas y descripción de tareas de las actuaciones
preventivas.
• Visualización GIS del acceso al centro objeto del correctivo.
• Imágenes descriptivas de las actuaciones correctivas, o preventivas (estado del equipo que ha
precisado una actuación sobre él)
La gestión documental estará imbricada con el elemento, campo o aspecto del mantenimiento
relacionado. En los casos en los que sea preciso, se integrará con la documentación de inventario. Se
describirá en la oferta la manera en que esta integración se realizará.
5.6. FUNCIONALIDADES DE REPORTING/INFORMES
La aplicación dispondrá de un módulo de análisis e informes que dote a Itelazpi de la información de
seguimiento del negocio adecuada para la toma de decisiones. Este módulo de inteligencia del
negocio permitirá la creación de informes a partir de los datos disponibles sobre el mantenimiento. El
adjudicatario definirá conjuntamente el detalle de los informes y su aspecto, así como la periodicidad
de la preparación de los mismos. Los informes deberán ser, al menos, los siguientes:
• Informe de total de nº de preventivos planificados/realizados, por año.
• Informes de nº de preventivos planificados/realizados, por contrato y año
• Informes de nº de preventivos planificados/realizados en el año en curso, por contrato y tipo de
activo.
• Informes de incumplimientos de Planes de mantenimiento, por contrato y tipo de activo
• Informes de nº de correctivos totales, por año
48 de 66
• Informes de nº de correctivos en el año en curso, mensuales, por año, por contrato y tipo de
activo
• Informes de tiempos de resolución y tiempos de desplazamiento en correctivos.
• Informe generado al momento de tareas pendientes fuera de plazo, por contrata y tipo de
activo
Se generará un cuadro de mando con los indicadores principales asociados a la actividad de
mantenimiento. Incluirá datos resumen de los informes anteriores, información de contratos/activos
cubiertos en nº y tipo, etc.
La herramienta deberá posibilitar a Itelazpi la generación de nuevos informes a medida de una
manera intuitiva, sin necesidad de generar código de programación. Se describirá el modo en que
estos informes son generados.
5.7. INTEGRACIÓN CON EL ERP CORPORATIVO DE ITELAZPI
La aplicación deberá integrarse al máximo nivel posible con el ERP corporativo RPS de Itelazpi. Se
describirá el nivel de integración propuesto, así como la estrategia que el licitador seguirá para
asegurarla.
En concreto, se propondrá el método de integración con los módulos RPS de compras (pedidos), y de
ventas (facturas), con el objeto de conseguir que sea posible relacionar tareas correctivas y
preventivas con contratos, pedidos a proveedores y facturas asociadas. También se definirán las
posibilidades con otros aspectos de la contabilidad de la compañía.
Dentro del alcance de la integración mínima requerida con el proyecto, se integrarán las siguientes
entidades y procesos:
• Maestro de clientes, proveedores y artículos. Serán tablas maestras únicas de tal forma que
cualquier cambio en el ERP se refleje automáticamente en la aplicación de mantenimiento y
viceversa.
• Generación en el ERP del pedido y albarán de compra de subcontratación y de compra de
materiales. El coste de la compra y su trazabilidad deberá quedar registrado en la orden de
mantenimiento y/o el contrato de mantenimiento para un posterior análisis
• Generación en el ERP del pedido y albarán de ventas para su facturación
49 de 66
5.8. INTEGRACIÓN CON EL ERP DE ALTEL
La aplicación deberá poder integrarse a nivel de documentación de mantenimiento con el ERP
corporativo de ALTEL. Este ERP dispone de los datos, parámetros medidos y partes de trabajo de los
preventivos y correctivos realizados por esta contrata de mantenimiento de los sistemas de difusión.
Para ello, la aplicación dispondrá de los métodos estándar y más modernos para interconexión
genérica con otras herramientas. El adjudicatario deberá colaborar en la definición y formato de los
intercambios de información de mantenimiento entre ambas aplicaciones.
5.9. INTEGRACIÓN CON LA APLICACIÓN DE INVENTARIO
Como es lógico, la aplicación de mantenimiento deberá estar estrechamente relacionada con el
inventario. La aplicación deberá mostrar todos los activos, sincronizados con el inventario, de una
manera jerarquizada por tipos, dependencias y de manera completa, incluyendo todos los elementos.
Se deberán poder asignar contratos y planes de mantenimiento por tipo de elemento, poder de una
manera intuitiva y rápida seleccionar elementos dentro de un tipo, filtrándolos por criterios como la
categoría de centros u otros.
Cuando, derivada de una tarea de mantenimiento, un activo cambie de parámetro (centro asociado,
activo de nivel superior del que depende…), esta modificación deberá ser también automáticamente
trasladada al inventario.
El licitador propondrá en su oferta la estrategia de sincronización que considera más adecuada, y
deberá ser implementada en caso de resultar adjudicatario.
5.10. REQUISITOS DE CAPACIDAD Y ESCALABILIDAD
La aplicación deberá soportar el crecimiento en la actividad del servicio, en cualquiera de los
parámetros que maneje: activos, nº de planes, nº de correctivos, etc…, sin que esto suponga una
carga económica adicional para ITELAZPI.
La aplicación deberá ser capaz de abarcar la volumetría de activos estimada, según el listado del
Apartado de Descripción de los Activos, sin ninguna merma apreciable en rendimiento y
navegabilidad. Se indicará el volumen máximo de activos soportado por la aplicación para un
rendimiento apropiado, según los requerimientos de hardware especificados.
50 de 66
El adjudicatario garantizará que el aumento de la carga que pueda soportar la aplicación, no penaliza
el rendimiento ni la disponibilidad de la misma.
El licitador especificará el método de licenciamiento. En caso de licencias por usuarios concurrentes,
se requiere un mínimo de 12 usuarios concurrentes. En caso de licencias nominales, se requiere un
mínimo de 60 usuarios nominales. Se indicarán las licencias incluidas, y el coste de futuras
ampliaciones que pudieran ser precisas.
Itelazpi dispondrá de la infraestructura hardware (servidores, red, PCs de usuarios..) y software de
soporte (licencias MS de SO, bases de datos, SharePoint…) para la implantación de la herramienta. El
licitador definirá explícitamente los requisitos Hardware y software precisos, tanto en los servidores de
la aplicación como en los clientes de acceso.
5.11. REQUISITOS DE FIABILIDAD Y RENDIMIENTO
El licitador garantizará que los accesos intranet/extranet a la aplicación estén disponibles dentro del
rango de funcionamiento de Itelazpi en cuanto a fiabilidad y rendimiento.
La aplicación será totalmente robusta y resistente a fallos, excepciones u otros errores, volviendo en
estos casos automáticamente a un paso anterior tras la emisión del mensaje descriptor del error.
Deberá incorporar todas aquellas funcionalidades conducentes a minimizar la introducción errónea de
datos en cada punto de interacción con el usuario, en función del contexto del dato introducido,
mediante el formato de datos requerido, valores máx/mínimos, menús desplegables con las opciones
válidas o listado de elementos existentes, etc.
Dentro del plan de pruebas que se plantee durante la puesta en marcha de la aplicación, se deberán
realizar pruebas específicas de rendimiento para los accesos en red en condiciones reales de volumen.
El acceso previsto es en modo de red de área local, y el plan de pruebas de rendimiento se realizará
en este entorno. No obstante, se deberá contemplar el acceso en modo Internet/Extranet a la
aplicación, sobre todo por parte de usuarios externos, en concreto contratas de mantenimiento.
El licitador describirá en su propuesta los aspectos de diseño o estructura que garantizan y optimizan
el rendimiento adecuado de la aplicación.
51 de 66
5.12. REQUISITOS DE ADMINISTRACIÓN
La aplicación propuesta deberá estar concebida, implantada y administrada de acuerdo a los
estándares de seguridad (ISO 27001, etc..) y de acuerdo a la legalidad aplicable (LOPD, etc..), de tal
manera que se garantice la confidencialidad, integridad, disponibilidad y trazabilidad de la información
procesada. ITELAZPI se reservará el derecho de establecer cláusulas de confidencialidad con el
adjudicatario.
Se deberá habilitar un mecanismo de integración con el sistema de directorio de ITELAZPI (en este
caso, Active Directory), que permita la autenticación de usuarios Intranet/Extranet/Internet haciendo
uso de las mismas credenciales de acceso, que ITELAZPI utiliza para el acceso al resto de los sistemas
propios.
Se deberán poder crear roles, a los cuales adherir las cuentas de acceso en función de los diferentes
perfiles deseados. Se deberá poder asignar niveles de permiso (consulta, descarga, modificación,
creación de planes, acceso solo a un cierto contrato…) para cada categoría de activos, contratos,
planes de mantenimiento.
Los usuarios con perfil administrador tendrán la capacidad de:
• Creación/modificación/eliminación (gestión) de roles y permisos para cada rol y tipo de acciones
• Gestión de tipos de activos, contratos, planes de mantenimiento
5.13. REQUISITOS DE ACCESO Y PRESENTACIÓN
El acceso a la aplicación, con cualquiera de los roles de acceso, será un interface web basado en IE.
En función del rol de la cuenta de acceso, se presentarán solo aquellas pantallas, opciones y menús o
funcionalidades a las cuales tiene acceso. Aquellas opciones no permitidas aparecerán menos
resaltadas o directamente no aparecerán. Se procurará un proceso de acceso a la aplicación con una
identificación única para ambas aplicaciones (inventario y mantenimiento), colaborando en su
integración con la estrategia de single sign on que implemente Itelazpi. Se describirán las
posibilidades de la herramienta en este aspecto.
Las páginas para acceso y las de administración de contenido, deberán poseer una interfaz gráfica lo
suficientemente enriquecida/automatizada como para garantizar un uso eficiente de la aplicación. Se
describirán las capacidades gráficas de la propuesta realizada. Esta descripción contendrá ejemplos
del aspecto de las pantallas y la navegabilidad que proporciona. Se describirán también todas aquellas
funcionalidades orientadas a mejorar el tránsito entre pantallas, despliegue de menús y opciones, así
como a mejorar la facilidad de introducción/modificación de datos.
52 de 66
La aplicación se deberá integrar tanto en el entorno Intranet como Extranet de Itelazpi, basado en la
actualidad en MS SharePoint. Se deberá detallar esta estrategia de integración.
La aplicación suministrada permitirá en el futuro un interface de usuario adaptado a movilidad. Como
mejora, el licitador podrá proponer dentro del alcance del proyecto la implantación de esta capa
orientada a movilidad. En este caso, la tecnología móvil actual de Itelazpi está basada en el sistema
operativo Android v4. En cualquier caso, la solución debe ser compatible para uso en movilidad con
dispositivos móviles basados en los principales sistemas operativos (ANDROID, IOS y WINDOWS
PHONE). Se describirá el alcance y arquitectura de esta solución en caso de ser ofertada.
También como mejora se podrá proponer una versión bilingüe Español-Euskara, que añada el euskera
como opción para la capa de presentación de la aplicación. En este caso el adjudicatario será el
responsable de una correcta correspondencia entre ambos idiomas de toda la capa de presentación.
5.14. REQUISITOS TECNOLÓGICOS.
Los requisitos tecnológicos son los mismos expresados en el Apartado de aplicación de inventario.
5.15. FORMACIÓN Y DOCUMENTACIÓN
Los licitantes propondrán un plan de formación de la aplicación, así como para la administración de
contenido y la administración general del sistema. ITELAZPI identificará quienes deberán recibir la
formación de usuario /Administración de Contenido.
Además de la formación inicial, se deberán plantear formaciones periódicas, con una cadencia no
mayor de 1 año. Las revisiones formativas serán obligatorias ante cualquier cambio mayor de la
aplicación (nueva versión, etc…).
El adjudicatario deberá aportar la documentación asociada a la aplicación, como documento de
entrega final del proyecto. Deberá constar, al menos, de un manual de usuario, y de un manual de
administración. Así mismo, ante cualquier modificación de la aplicación, el adjudicatario deberá enviar
la correspondiente actualización.
En las posibles acciones de integración, el adjudicatario entregará la documentación requerida por el
integrador de la otra aplicación: arquitectura técnica, arquitectura de la información, modelo de datos,
especificaciones de comunicación (Web Services, XML, etc….).
53 de 66
5.16. MANTENIMIENTO
Dentro del suministro de la herramienta de mantenimiento, no se contempla el servicio de soporte y
mantenimiento evolutivo de la aplicación tras la fase de entrega y aceptación de la misma. No
obstante, se deberá especificar el coste de estos servicios para ejercicios posteriores. Sí se debe
incluir, sin embargo, en el precio total de la oferta el precio de la garantía extendida, que
comprenderá el coste de licencias y actualizaciones de versión hasta el 31 de diciembre de 2016.
54 de 66
6. METODOLOGIA.
En este apartado, el licitador deberá desglosar los medios humanos puestos a disposición del
proyecto, su organización y la planificación propuesta.
6.1. EQUIPO DE PROYECTO Y CUALIFICACION TECNICA DEL LICITADOR
El licitador deberá presentar en su oferta y dedicar al proyecto, en caso de resultar adjudicatario, la
composición del equipo de proyecto, incluyendo las funciones y el nº de personas con los perfiles
exigidos que resulten necesarias para el cumplimiento efectivo de las funciones requeridas en los
pliegos y los compromisos adquiridos en su oferta.
Como valoración de la solvencia del licitador, éste deberá listar los certificados disponibles a nivel de
compañía, referentes a los entornos de Microsoft y de la aplicación de mantenimiento ofertada.
Se requiere que el licitador disponga como mínimo de una Certificación Microsoft Gold Partner, en
vigencia en 2014, para la zona de España, en alguna de las siguientes competencias:
• Plataforma de datos
• Desarrollo de aplicaciones
• Colaboración y contenido
Se valorarán las certificaciones MS Gold o Silver adicionales a la mínima exigida, en los entornos de
competencia: Server Platform, Data Platform, Identidad y acceso, y Dispositivos e implementación.
Asimismo se valorará cualquier otro certificado o reconocimiento que refuerce el compromiso con las
soluciones del fabricante.
Se valorarán también niveles de certificación en la aplicación de mantenimiento. Cuando la aplicación
de mantenimiento sea de desarrollo propio del licitador, éste no precisará lógicamente de certificación
alguna, y deberá señalarlo como “aplicación propia”.
55 de 66
El personal dedicado que compondrá el equipo de proyecto estará integrado como mínimo por los
siguientes grupos:
• Director de Proyecto (una persona, con dedicación completa al contrato durante la
implantación)
• Analista/Consultor para la fase inicial de diseño (dedicación parcial)
• Analista informático (dedicación parcial) con experiencia en alguno de estos entornos:
- Bases de Datos
- Web y Colaboración
- Desarrollo de software
- Aplicación de mantenimiento ofertada
• Técnicos de desarrollo (al menos 4).
Se valorarán dedicaciones completas al proyecto adicionales a las mínimas exigidas.
Cuando, en todo lo referente a este contrato, se hace mención a personas con dedicación completa al
contrato, se entiende que se refiere a personas en su integridad con un contrato laboral de jornada
completa, de acuerdo al convenio vigente en la organización, no considerándose la suma de
dedicaciones parciales como equivalentes a dedicaciones totales.
Perfil del Director de Proyecto.
Requisitos imprescindibles: Formación de Ingeniero Superior en Telecomunicaciones (comprensión del
negocio de Itelazpi), con al menos 5 años de experiencia demostrable como Jefe de proyectos
informáticos (capacidad de dirección del proyecto). La experiencia se demostrará mediante el
correspondiente certificado nominativo emitido por la organización en la que ha prestado dichos
servicios, listando los proyectos que ha dirigido y las fechas de ejecución. Durante la implantación del
proyecto, su puesto de trabajo deberá estar ubicado en la CAE.
Otros requisitos valorables: Superior formación de postgrado, años de experiencia adicionales a los
mínimos exigidos, experiencia en proyectos del sector telecomunicaciones, certificaciones adicionales
relevantes para el contrato, en concreto, como MS MCSE, o acreditar una formación master postgrado
en Gestión de Proyectos o Administración de Negocios. Certificación avanzada en buenas prácticas de
gestión de IT (ITIL Foundation o superior). Asimismo, se valorará tener un alto dominio de euskera,
escrito y hablado.
56 de 66
Perfil del Analista de Sistemas.
Requisitos imprescindibles: formación específica universitaria de grado medio en Ingeniería
Informática o de Telecomunicaciones. Experiencia de al menos 3 años como Analista de sistemas en
proyectos similares al licitado en naturaleza técnica y/o funcional. La experiencia se demostrará
listando los proyectos en los que ha participado y las fechas de ejecución.
Otros requisitos valorables: formación específica universitaria de master en Ingeniería Informática o
de Telecomunicaciones (antigua Ingeniería superior de telecomunicaciones). Experiencia adicional a la
exigida, y experiencia en proyectos del sector telecomunicaciones. Experiencia en dirección de
proyectos. Certificación de Microsoft MCSE Data Platform, MCSE SharePoint, MOS Expert. Puesto de
trabajo durante la ejecución de la implantación en la CAE. Asimismo, se valorará tener un alto dominio
de euskera, escrito y hablado.
Perfil de los Técnicos de desarrollo.
Requisitos imprescindibles: Formación mínima de Ciclo Formativo (Formación Profesional) de Grado
Superior en Telecomunicaciones o Informática y con experiencia mínima de 2 años como Técnico de
desarrollo o implementación de las soluciones ofertadas. Conocimientos expertos demostrables de las
plataformas y lenguajes a utilizar bien por acreditaciones formativas, bien por experiencia directa on-
job acreditable.
Otros requisitos valorables: formación específica universitaria de grado en Ingeniería de
Telecomunicaciones (antigua Ingeniería técnica de telecomunicaciones) o superior. Experiencia
adicional a la exigida, y experiencia en proyectos del sector de telecomunicaciones. Puesto de trabajo
durante la implantación en la CAE.. Asimismo, se valorará tener un alto dominio de euskera, escrito y
hablado.
Se deberá acreditar la pertenencia del personal dedicado a la organización licitante. No se permite la
subcontratación del personal dedicado al contrato.
ITELAZPI garantiza la confidencialidad de los datos identificativos de las personas propuestas, tanto
los aportados en la documentación técnica de la oferta, como la contenida en la acreditación de la
solvencia técnica y en el compromiso de vinculación de medios personales.
57 de 66
ITELAZPI podrá, en caso de detectarse continuadamente anomalías o insuficiente calidad del trabajo
realizado por alguna de las personas dedicadas al contrato, solicitar su sustitución, solicitud que
deberá ser atendida por el adjudicatario en un plazo inferior a un mes.
Los analistas y el director de proyecto deberán trasladarse a ITELAZPI cuando el desarrollo de sus
funciones lo requiera, o sean requeridos para sesiones informativas o de formación.
El requerimiento de la ubicación se justifica en razón a la necesidad de mantener continuos contactos
entre el personal del contratista y el de ITELAZPI, en muchos casos de manera inmediata, sin previa
planificación, e incluso la necesidad de acudir a centros. Por esta misma razón y al objeto de asegurar
una perfecta transición, se exige como requisito de solvencia la existencia de sede del licitador abierta
y en funcionamiento en el ámbito de la CAE en el momento de presentación de las ofertas.
Otros medios materiales y humanos.
La empresa oferente deberá incluir en su propuesta técnica los medios adicionales puestos a
disposición del contrato, ya sea en mayor nº de técnicos dedicados con los perfiles y funciones
exigidas, o en funciones de apoyo no descritas que pueden redundar en un mejor funcionamiento del
proyecto. Se detallarán los medios humanos y materiales destinados a estas funciones de apoyo, si
existieran, así como la operativa, estructura organizativa en la que se integran, y ventajas en la
automatización de los procesos que se obtienen de ello.
58 de 66
6.2. PLAN DE PROYECTO
El licitador deberá describir en este apartado su propuesta de Plan de proyecto. Deberá incluir al
menos los siguientes aspectos.
• Metodología de trabajo y modelo de relación del proyecto
• Plan de riesgos y contingencias
• Cronograma y plan de trabajo: indicando fases-actividades-tareas, cronograma de ejecución y
sus hitos y entregables. La responsabilidad primaria de la planificación, ejecución y control de
estas tareas es del adjudicatario
• Desglose de horas estimadas de trabajo por cada persona dedicada al proyecto.
• Descripción detallada del contenido y funciones a realizar en cada Fase-actividad-tareas
descrita.
• Descripción de los hitos y entregables, en contenido y forma, cómo mínimo Diseño conceptual,
modelo entidad-relación, diseño funcional, diseño técnico (tablas y pantallas) y manual de
usuario
• Descripción de los planes de pruebas y aceptación propuestos.
• Plan de migración y carga inicial de datos.
• Tabla de responsables y procedimientos de gestión principales: responsable y usuario de las
altas, bajas y modificaciones en las distintas funcionalidades
• Plan de acciones de comunicación y formación a desarrollar. Descripción de contenido y
calendario por perfil de usuario interno y externo
Se establece un período máximo de implantación de la herramienta de nueve (9) meses, a partir de la
fecha de adjudicación. Debe contener al menos las tareas principales de definición y diseño,
desarrollo, carga de datos iniciales, implantación, parametrización, integración, pruebas de
aceptación, formación. El proyecto debe estar enfocado a pequeñas entregas de no más de un
trimestre. En este momento de finalización de la implantación se realizará la aceptación provisional
del proyecto.
Tras la implantación, se establece un periodo de al menos 4 meses, durante el cual el adjudicatario
deberá prestar un soporte post-implantación en el que se atiendan de manera inmediata consultas, y
se corrijan de manera urgente defectos que pudieran ser detectados en la herramienta. El proyecto se
considerará finalizado al expirar este periodo de soporte post-implantación, y se realizará la
aceptación definitiva del proyecto. A partir de este momento comenzará el periodo de garantía,
establecido en al menos dos ejercicios, hasta finales de 2016.
59 de 66
El licitador describirá la metodología de desarrollo e implantación de aplicaciones que sigue, así como
su propuesta de adecuación a este proyecto en concreto.
60 de 66
7. ASPECTOS MEDIOAMBIENTALES.
A fin de minimizar el consumo de papel, la documentación generada durante el encargo se entregará,
preferiblemente, en soporte electrónico a través de correo electrónico o a través de un servidor (con
enlaces para descargar los documentos o similar) o, en última instancia, en CD, DVD o similar
regrabable y abierto para su posterior reutilización.
Cuando sea necesaria la impresión en papel, se seguirán las siguientes pautas:
• establecer previamente el número de copias, limitando éstas al mínimo imprescindible.
• el papel ha de tener un contenido mínimo del 20% de fibras de madera provenientes de
explotaciones forestales sostenibles (FSC, PEFC o equivalente) y/o fibras recicladas.
• ha de ser libre de cloro elemental.
• ha de tener una durabilidad superior a 100 años
• preferentemente, imprimir los documentos a doble cara, en blanco y negro y, cuando sea
factible, dos páginas por cara.
• encuadernar de manera que se favorezca el reciclaje.
• ha de ser idóneo para impresión y fotocopia
61 de 66
8. ASPECTOS RELATIVOS A LA PREVENCIÓN DE RIESGOS LABORALES.
El contratista estará obligado al cumplimiento de las normas legales vigentes y procedimientos
establecidos por ITELAZPI en materia de seguridad y salud laboral, al mantenimiento de la vigencia de
la formación que, en dicha materia, sea exigida y al impulso y promoción de la política asumida por
ITELAZPI. Particularmente, deberá informar a los responsables técnicos de ITELAZPI de las anomalías
y riesgos que advierta en las instalaciones que visite como consecuencia de la ejecución de este
contrato.
ITELAZPI controlará, a través de la entidad con la que tiene concertado el Servicio de Prevención
Ajeno, el cumplimiento de las obligaciones jurídico-laborales previstas en la legislación vigente.
En el supuesto de que el adjudicatario concurra en centros o dependencias de ITELAZPI, ésta
establecerá los medios necesarios en cuanto a protección de los riesgos laborales de los trabajadores
y la coordinación de actividad preventiva entre empresas, entre otros, facilintando al adjudicatario-en
el momento de la notificación de la adjudicación- la documentación pertinente que éste deberá
cumplimentar correctamente y remitir al servicio de prevención de ITELAZPI.
Como resultado del correcto cumplimiento de dicha documentación el contratista obtendrá la
calificación de empresa homologada en materia de seguridad y salud laboral y, por tanto, apta para la
contratación con ITELAZPI, S.A.
ITELAZPI podrá rechazar, posponer o paralizar la ejecución de las prestaciones contractuales, e
incluso resolver el Contrato, si la empresa adjudicataria no puede realizarlos con las condiciones de
seguridad y salud exigidas. Serán de cargo del adjudicatario cuantos gastos e instalaciones sea
preciso dotar al servicio de acuerdo con las normas laborales, generales o sectoriales que sean de
aplicación.
En caso de incumplimiento grave o reiterado de las obligaciones de seguridad y salud, ITELAZPI, con
independencia de lo previsto en el párrafo precedente, podrá proceder a la retención de las
cantidades adeudadas al adjudicatario hasta la definitiva liquidación del Contrato.
62 de 66
9. TRATAMIENTO DE DATOS DE CARÁCTER PERSONAL.
Las partes se comprometen al estricto cumplimiento de la normativa vigente en materia de
tratamiento de datos de carácter personal (LOPD y normas de desarrollo). En este sentido, el
contratista aportará la información relativa al personal vinculado al contrato, con el consentimiento de
éste. ITELAZPI se compromete a declarar los ficheros correspondientes y a utilizar los referidos datos
a los exclusivos fines de cumplimiento del contrato, otorgando a los afectados los derechos
reconocidos por la vigente legislación. Los mencionados datos únicamente podrán ser cedidos al
Servicio Ajeno de Prevención de ITELAZPI, al objeto de velar por el cumplimiento de la normativa
aplicable en materia de Seguridad y Salud Laboral en el marco del presente contrato.
El personal de la empresa adjudicataria deberá observar en todo momento el secreto profesional y
deber de confidencialidad sobre todos los datos a los que pudiera tener acceso incidentalmente en el
cumplimiento de las tareas encomendadas. El personal de la empresa adjudicataria queda obligado a
no revelar, transferir, ceder o comunicar de cualquier forma los datos a terceras personas, obligación
que se mantendrá una vez finalizada su relación con ésta. La empresa adjudicataria se compromete a
comunicar y hacer cumplir a su personal estas obligaciones y, en concreto, las relativas al deber de
secreto.
La empresa adjudicataria que incumpla lo establecido en los apartados anteriores será considerada
responsable del tratamiento, respondiendo de las infracciones en que hubiera incurrido, así como de
cualquier reclamación que por las personas interesadas se interponga ante la Agencia de Protección
de Datos y de la indemnización que, en su caso, se reconozca a la persona afectada que ejercite la
acción de responsabilidad por el daño o lesión que sufra en sus bienes o derechos.
63 de 66
10. SECRETO Y CONFIDENCIALIDAD.
El contratista estará obligado a guardar estricta confidencialidad de la información relativa a los
sistemas e infraestructura de ITELAZPI que conozca en ejercicio de sus funciones, así como a no
ceder a terceros ninguna documentación sobre aquellas sin el consentimiento previo y expreso de
ITELAZPI. Si se advirtiera, vigente el contrato, cualquier anomalía a este respecto se procederá a la
inmediata rescisión del contrato, sin perjuicio del ejercicio de acciones legales.
64 de 66
11. PRESUPUESTO DE LA LICITACION Y PLAZO DEL CONTRATO.
El importe máximo de licitación se establece en 200.000 €, IVA no incluido. La facturación del contrato
se realizará: el 80% del precio a la finalización en conformidad de la implantación (plazo máximo de
implantación 9 meses), y el 20% restante concluido en conformidad el periodo de soporte post-
implantación (mínimo 4 meses).
La duración se establece por un periodo que comprende desde la firma del contrato, hasta el 31 de
diciembre de 2016.
Se establece una garantía definitiva para el adjudicatario del 8% del importe máximo de la licitación.
Esta garantía se reintegrará, en su caso, al final del periodo de garantía extendida, previsto el 31 de
Diciembre de 2016.
65 de 66
12. PRESENTACION DE LAS OFERTAS.
La oferta técnica a presentar en el Sobre 2A se desarrollará según el siguiente índice:
1. Aplicación de inventario
Se describirá la propuesta de inventario según el índice de su apartado en este pliego
2. Aplicación de mantenimiento
Se describirá la propuesta de mantenimiento según el índice de su apartado en este pliego
3. Metodología de proyecto
a. Equipo de proyecto
b. Plan de proyecto
4. Mejoras propuestas, incluyendo su valoración económica justificada.
En todos los citados apartados, la licitadora se ajustará al orden secuencial establecido en el PBT.
En este sobre, el licitador también podrá incluir toda la documentación que ponga de manifiesto las
capacidades, conocimientos y medios que desea adscribir o involucrar en la ejecución del contrato.
Todos los medios y capacidades que el licitador manifieste poner a disposición de la ejecución del
contrato, serán exigibles en caso de resultar adjudicatario.
La oferta técnica a presentar en el Sobre 2B se desarrollará según el siguiente índice:
- Certificaciones vigentes en 2014 de la organización licitante como partner de Microsoft
adicional al mínimo exigido. Se indicarán TODAS las certificaciones Microsoft por ámbitos
de competencia. (2 puntos por certificación Gold y 1 punto por certificación Silver
adicionales al mínimo exigido, en: Plataforma de Servidores, Plataforma de Datos,
Desarrollo de Aplicaciones, Colaboración y contenido, Identidad y acceso, o Dispositivos e
implementación). La puntuación se otorgará hasta un máximo de 10 puntos. Además de
la documentación justificativa, se completará la siguiente Tabla con todas las
certificaciones de que dispone el licitador:
66 de 66
Competencias Está inscrito como Silver/Gold (indicar cual de las dos)
Desarrollo de Aplicaciones SILVER/GOLD
Colaboración y Contenido SILVER/GOLD
Plataforma de Servidores SILVER/GOLD
Plataforma de Datos SILVER/GOLD
Identidad y Acceso SILVER/GOLD
Dispositivos e Implementación SILVER/GOLD
*****
