El Suministro deberá incluir todos aquellos ítems que no hubiesen sido expresamente indicados en la presente sección, pero que pueda inferirse razonablemente que son necesarios para satisfacer el requisito de suministro indicado, por lo tanto, dichos bienes serán suministrados por el Proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el Contrato.

Los bienes suministrados deberán ajustarse a las especificaciones técnicas y las normas estipuladas en este apartado. En caso de que no se haga referencia a una norma aplicable, la norma será aquella que resulte equivalente o superior a las normas oficiales de la República del Paraguay. Cualquier cambio de dichos códigos o normas durante la ejecución del contrato se aplicará solamente con la aprobación de la contratante y dicho cambio se regirá de conformidad a la cláusula de adendas y cambios.

El Proveedor tendrá derecho a rehusar responsabilidad por cualquier diseño, dato, plano, especificación u otro documento, o por cualquier modificación proporcionada o diseñada por o en nombre de la Contratante, mediante notificación a la misma de dicho rechazo.

ESPECIFICACIONES TÉCNICAS

 

Ítem	Código Catálogo	Descripción del Bien	Unidad de Medida	Presentación	Cantidad
1	43222634-001	EQUIPO DE MONITOREO	Unidad	UNIDAD	1

 

1. La solución deberá estar compuesta por:

1.1. Para el almacenamiento masivo de datos a ser utilizado en el estudio histórico de los mismos se deberá proveer 1 (un) appliance físico dedicado, con espacio utilizable en disco de 15 TB como mínimo y la configuración de RAID es optativa.

1.2. Para el monitoreo y el análisis de los datos previamente almacenados, que fueron recolectados desde la red, se deberá proveer un appliance que podrá ser del tipo físico o virtual, con módulos que permiten el análisis del performance midiendo estos parámetros recolectados, para posteriormente modelar las vistas de control.

1.3. La herramienta contará con licenciamiento perpetuo para el appliance y las funcionalidades de este.

1.4. La herramienta deberá brindar dentro del soporte del fabricante la posibilidad de

actualización de firmware y bases de funcionalidades de 12 meses como mínimo.

1.5. La herramienta deberá realizar el análisis de los datos recolectados desde 10 puntos de conexión como mínimo en la red.

 

2. Características Técnicas:

2.1. Cuatro conectores Gigabit Ethernet, además de una conexión 10/100/1000 separada para la interconexión con su consola y para tareas administrativas, como mínimo.

2.2. Este módulo tendrá una consola para que a nivel operativo y de análisis de fallas se pueda analizar los datos obtenidos.

2.3. Esta consola también podrá procesar archivos capturados previamente y guardados en formato reconocido.

2.4. La consola proveerá para el análisis un selector de tiempo donde visualmente o por medio de un formulario se pueda seleccionar un lapso sobre el cual se desea realizar el análisis.

2.5. Se podrá representar en un gráfico para visualizar el tráfico del lapso seleccionado y en la cual los ejes "X" e "Y" sean modificables en su escala con el fin de obtener mayor detalle en esta visualización y así facilitar el análisis.

2.6. El gráfico podrá ser modificado en sus métricas para que reflejen bits/seg, bytes/seg, paquetes/seg; y podrá ser desplegada en escala lineal o logarítmica.

2.7. Existirán en la consola tablas con diversas características de tráfico tales como VLAN ID, subred, IP origen, IP destino, puerto, protocolo, entre otros.

2.8. Se dispondrá de un gráfico de torta circular donde, según el ordenamiento de las tablas, se dibuje el gráfico para representar las entradas más importantes de acuerdo con dicho ordenamiento.

2.9. El gráfico del punto anterior también estará disponible como gráfico de barras. 2.9.1. Las tablas de datos disponibles para cada intervalo seleccionado deberán tener diversas vistas como:

2.9.1.1. Un resumen de los paquetes recibidos.

2.9.1.2. Errores los paquetes recibidos.

2.9.1.3. Tráfico por dirección IP asociado con puerto, red, dirección MAC, IP destino, VLAN ID, etc.

2.9.1.4. Tráfico por puerto asociado con el protocolo IP, la dirección MAC, y la tasa de trasmisión en Paquetes/seg y Bytes/seg, etc.

2.9.1.5. Subredes y su tráfico asociado a las direcciones IP, con datos de bytes y tasa de transmisión.

2.9.1.6. Direcciones MAC.

2.9.1.7. Conversaciones entre estaciones con direcciones IP.

2.9.1.8. Sockets relacionando direcciones IP con puertos lógicos y las tasas de transmisión.

2.9.1.9. VLAN, mostrando estadísticas por VLAN.

2.10. Las estadísticas en las tablas deben ser seleccionables de modo que el gráfico desplegado se refiera solamente a las instancias de las tablas que se han seleccionado.

2.11. Los datos en las tablas podrán ser ordenados de acuerdo con las columnas que las componen.

2.12. La consola de este módulo, además, permitirá que se seleccionen datos dentro del intervalo de tiempo para ser recuperados y analizados en un sistema experto que permita ver entidades existentes en las diferentes capas o encabezados del tráfico, así como ver los paquetes mismos y sus encapsulamientos. Este sistema experto será de una naturaleza tal que:

2.12.1. Deberá permitir la creación de perfiles de filtros donde puedan crearse diversos filtros con nombres específicos facilitando el trabajo del usuario.

2.12.2. Deberá soportar DIAGNOSTICOS en diferentes niveles del modelo OSI. Estas deben incluir:

2.12.2.1. Red

2.12.2.2. Direcciones IP duplicadas

2.12.2.3. Misdirected frame

2.12.2.4. Time-to live expiring

2.12.2.5. Transporte

2.12.2.6. Slow server, Window Size exceeded, Slow File Server

2.12.3. Deberá permitir la captura parcial de paquetes, limitándose a capturar 32, 64, 128,256, 512 o 1024 bytes iniciales, evitando que se capture el resto de las tramas.

2.13. Deberá permitir la interpretación del tráfico clara e inteligible dividida por color conforme a la capa correspondiente.

2.14. Deberá desplegar los datos en formato hexadecimal, e interpretando los caracteres en ASCII o EBCDIC

2.15. Deberá contar con métodos rápidos que permiten ir a una trama digitando el número de esta.

2.16. Deberá desplegar el tiempo relativo entre tramas subsecuentes.

2.17. Deberá desplegar el tiempo relativo a una trama específica marcada por el operador.

2.18. Deberá desplegar la hora y la fecha absolutas en los que una trama fue capturada.

2.19. Deberá permitir la búsqueda por texto a secuencia de caracteres en una captura.

2.20. Deberá contar con un filtro rápido que con un solo "clic se filtren los paquetes que estén relacionados a un diagnóstico encontrado.

2.21. Deberá contar con filtros de pos-captura por:

2.21.1. Por dirección IP o MAC

2.21.2. Filtros por conversación entre dos estaciones a través de la selección del nombre o la dirección IP

2.21.3. Filtro por protocolos

2.21.4. Filtro de patrones de datos (Bytes y bits) permitiendo la configuración de patrones dentro de la trama

2.21.5. Tamaño de trama

2.21.6. Deberá permitir crear combinaciones de criterios.

2.22. Deberá poseer los siguientes gráficos estadísticos:

2.22.1. Hosts que más utilizan la red (Top 10Hosts) (bytes, paquetes y broadcasts).

2.22.2. Conexiones que más utilizan la red.

2.22.3. Distribución de la utilización de la red.

2.22.4. Utilización, errores, broadcasts vs. Tiempo.

2.22.5. Distribución de Protocolos en formato de barras, pie o tabla

2.23. Deberá desplegar tablas que listan las conexiones entre dispositivos con direcciones IP que muestran las cantidades de Bytes y tramas enviados o recibidos por cada máquina, entre otras informaciones (indicar).

2.24. Los siguientes gráficos que estarán disponibles:

2.24.1. Paquetes y bytes.

2.24.2. Errores por Segundo

2.24.3. Tamaño de paquetes

2.24.4. Top Hosts

2.24.5. Top Conversations

2.24.6. Top Protocols

2.24.7. Tempo de respuesta de aplicaciones

2.25. Este sistema experto poseerá vistas en las cuales se podrá ver la descodificación del tráfico analizado, un mapa de tráfico que muestre las relaciones entre estaciones y la distribución de los protocolos en el intervalo.

2.26. Además, este experto deberá contar con una tabla que por capas muestre las entidades contenidas en el tráfico y permita seguir filtrando datos hasta llegar al análisis de una sola entidad ya sea esta una IP, red, conexión TCP, flujo de datos UDP o una sola alerta de anomalía.

 

3. Monitoreo de Aplicaciones:

La solución ofertada deberá contar con la capacidad por medio de una consola adicional de análisis de aplicaciones que sea capaz de auto descubrir aplicaciones corriendo en la red y analizar su tiempo de respuesta y comportamiento.

3.1. Esta solución deberá de desglosar el tiempo de respuesta de aplicaciones en Tiempo en el Servidor y Tiempo de Transferencia de Datos.

3.2. Se necesita que las aplicaciones en este módulo se auto- descubran, y que también puedan ser dadas de alta vía rango de puertos TCP/UDP o sockets.

3.3. Como datos requeridos a las estadísticas brindadas con este módulo de monitoreo LAN se necesita las siguientes estadísticas: consumo de ancho de banda por aplicación, por cliente, por servidor, por VLAN, por QoS y por tiempo de intervalo.

3.4. Se necesita que el módulo solicitado pueda entregar estadísticas presentadas en forma tabular y además en forma gráfica.

3.5. La solución de monitoreo de aplicaciones debe permitir segmentar la vista por VLAN, Tiempo, Clientes, Servidores y aplicación, QOS, tráfico de VOIP. Las vistas deben estar relacionadas de tal forma que un cambio en una de las vistas afecte a todas las demás.

3.6. La solución deberá ser agnóstica respecto a marcas o modelos de equipos de red o conectados a la red existentes en el ecosistema.

3.7. La solución deberá contar con soporte de protocolos al menos para:

3.7.1. ICMP

3.7.2. IGMP

3.7.3. TCP

3.7.4. EGP

3.7.5. IGP

3.7.6. UDP

3.7.7. GRE

3.7.8. DSR

3.7.9. ESP

3.7.10. AH

3.7.11. TLSP

3.7.12. CFTP

3.7.13. DGP

3.7.14. TCF

3.7.15. EIGRP

3.7.16. 16. OSPF

3.7.17. 17. LARP

3.7.18. 18. MTP

3.7.19. 19. VRRP

3.7.20. 20. PGM

3.7.21. 21. L2TP

3.7.22. 22. DDX

3.7.23. 23. IATP

3.7.24. 24. STP

3.8. Los análisis deberán estar soportados al menos para:

3.8.1. Cc: mail

3.8.2. 2. Lotus Notes

3.8.3. 3. HTTP/Web

3.8.4. 4. Oracle

3.8.5. 5. NFS

3.8.6. 6. Internet Mail

3.8.7. 7. MeetingMaker

3.8.8. 8. Entrypoint

3.8.9. 9. DB2

3.8.10. FTP

3.8.11. MS Mail

3.8.12. MS Exchange

3.8.13. Backweb

3.8.14. MS-SQL

3.8.15. TFTP

3.8.16. VINES

3.8.17. MSODBC

3.8.18. Telnet

3.8.19. QuickMail

3.8.20. Java Scripts

3.8.21. Sybase

3.8.22. X-Win

3.8.23. Audio Ingres

3.8.24. SoftPC

3.8.25. Real Audio

3.8.26. Gupta Gopher

3.8.27. AOL UUCP

3.8.28. MS-RPC H.323 Peoplesoft Citrix

3.8.29. MS-Media RTP/RTCP SAP R3 Timbuktu

3.8.30. MS-SNA Server T.120 PCAnywhere

3.8.31. MS-SMS CU-Seeme

3.8.32. MS-MQS

3.8.33. MS-Terminal Svr

3.8.34. talkMATIP

3.8.35. Filenet

3.8.36. Quicktime

3.8.37. HTTP

3.8.38. ntalk

3.8.39. VivoActive

3.8.40. SMTP

3.8.41. IRC

3.8.42. Shockwave

3.8.43. NNTP

3.8.44. iChat

3.8.45. VDOLive

3.8.46. FTP

3.8.47. IVisit StreamWorks

3.8.48. Telnet

3.8.49. IMAP

3.8.50. Y protocolos a definir por el usuario

 

4. Monitoreo de Voz.

Además, la solución deberá ser capaz de analizar el tráfico de sobre VoIP, y que permita decodificar y hacer troubleshooting de protocolos de VoIP como:

4.1. H.323 (v4) incluyendo:

4.1.1. H.225 (v4) Call Signaling

4.1.2. H.245 (v8) Media Control

4.2. RAS (v4)-Registration, Admission, and Status

4.3. H235 (v3)-Security

4.4. Faststart

4.5. IP-Session Initialization

4.6. SDP-Session Description

4.7. SAP-Session Announcement

4.8. MGCP-Media Gateway Control

4.9. MEGACO / H.248-Media Gateway Control

4.10. RTP-Realtime Transport

4.11. RTCP-RTP Control

4.12. RTSP-Realtime Streaming Protocol

4.13. H.261-Video Encoding

4.14. H.263-Video Encoding

4.15. La solución de monitoreo de tráfico de voz deberá de dar alarmas de pérdida de paquetes, "jitter" o retardo de las conversaciones.

 

5. Características del servidor de monitoreo centralizado.

La solución ofertada será tal que pueda ser accedida con la totalidad de las funcionalidades con un browser o por medio de un cliente liviano que se pueda instalar en cualquier computadora personal.

5.1. La solución al recuperar tráfico deberá permitir utilizar filtros de tipo Dirección IP, direcciones MAC y patrones de trama para el periodo de análisis seleccionable por el usuario.

5.2. La solución ofertada podrá brindar estadísticas en tiempo real y almacenará información histórica como reportes hasta por un año.

5.3. El despliegue de la información para su monitoreo ya sea en tiempo real como para el último mes deberá estar basado en tableros configurables que podrán contener diferentes paneles o gráficos de información. Estos tableros deberán ser por usuario. Un usuario podrá compartir estos tableros de forma que puedan ser visualizados por otros usuarios.

5.4. Estos tableros al menos podrán contener información de la siguiente clase:

5.4.1. Uso de los enlaces monitoreados en total y desglosados por

5.4.1.1. Aplicación

5.4.1.2. Hosts

5.4.1.3. Grupos de Aplicaciones

5.4.1.4. Grupos de Hosts

5.4.1.5. Conversaciones entre Hosts

5.4.2. Uso de una aplicación en total y desglosado por: 5.4.2.1. Aplicación

5.4.2.2. Hosts

5.4.2.3. Grupos de Aplicaciones

5.4.2.4. Grupos de Hosts

5.4.2.5. Conversaciones entre Hosts

5.5. Los tableros deberán permitir visualizar para un Host.

5.5.1. Su top aplicaciones

5.5.2. Su top conversaciones hacia y desde el Host.

5.6. Los tableros deben permitir ver las aplicaciones para un host.

5.7. Las capturas de paquetes que sean recuperables deberán poder ser exportadas en formatos ya sea .cap o como pcap para su análisis posterior o almacenamiento.

5.8. La solución ofertada deberá permitir que se generen diagramas de las conexiones TCP y como los paquetes se intercambian entre el servidor y el cliente, basado en capturas de tráfico.

5.9. Tendrá capacidad para realizar el inventario de subredes, VLAN y QOS de modo que cada una de ellas sea vista como un enlace separado para permitir el monitoreo del tráfico de cada objeto en forma individual por cada segmento IP.

5.10. La solución podrá calcular y graficar el tiempo de respuesta de aplicaciones mostrándolo como tiempo de red y tiempo de servidor por separado.

5.11. Para VoIP se contará con las siguientes capacidades.

5.11.1. Registro de las llamadas en proceso

5.11.2. MOS de las llamadas

5.11.3. Origen y destino de las llamadas

5.12. La solución será compatible al menos con los protocolos de voz paquetizada.

5.12.1. SIP

5.12.2. H323

5.13. En los gráficos existirán capacidades de acercamiento por despliegue (drill-down), donde basado en una vista se puede ir a otra con más detalle acerca de las estadísticas presentadas en la vista original.

5.14. La solución brindará la capacidad de enviar alertas en casos configurables por las siguientes vías

5.14.1. EMAIL

5.14.2. Ejecutando un script

5.14.3. Trap SNMP

5.15. Las estadísticas relativas al tráfico comprenderán al menos

5.15.1. Throughput

5.15.2. Volumen de tráfico

5.15.3. Paquetes

5.16. Respecto al tráfico WEB podrán inventariarse y darse de alta aplicaciones por su URL.

5.17. La resolución con que son visualizados los datos más recientes podrá seleccionarse hasta una escala tan granular como milisegundos.

5.18. Los ejes de los gráficos más importantes podrán ser lineales o logarítmicos a elección del usuario para mejor lectura de los datos.

5.19. Existirá la posibilidad de crear tanto grupos de elementos como grupos de usuarios para el monitoreo de las estadísticas de modo que, si un grupo de interfaces tienen relación, puedan agruparse para un análisis más rápido y seguro.

5.20. Cuando los umbrales de las variables a las cuales se configuren alertas sean sobrepasados, además de generar la alerta correspondiente por los medios mencionados antes, se deberá contar con un visor de alarmas que de vista retrospectiva de estas alarmas.

5.21. Los reportes deberán estar disponibles en diferentes formatos que al menos comprenderán:

5.21.1. Reportes inmediatos que se generen a partir de una vista en tiempo real o histórica

5.21.2. Reportes calendarizados que puedan ser generados cada cierto periodo de tiempo y que al menos puedan ser:

5.21.2.1. Enviados por Email en formato pdf.

5.21.2.2. Publicados en el servidor central de la solución ofertada para ser accedidos vía Web.

5.22. La solución podrá graficar tráfico en forma cuantitativa (volumetría) así como también gráficos de tiempo de respuesta para las aplicaciones en las cuales se solicite esa información.

5.23. No solo podrá graficar el tiempo de respuesta de una aplicación sino entregar graficas entregando rankings de:

5.23.1. Peores aplicaciones

5.23.2. Peores Servers

5.23.3. Peores Clientes

5.24. Para cada una de estas instancias se podrá ver el tiempo de respuesta de la aplicación en cuestión.

5.25. La solución permitirá analizar la cantidad de respuestas que las aplicaciones haya servido y decir cuántas han sido exitosas y cuantas han sido fallidas.

5.26. La solución podrá entregar un reporte diciendo qué cantidad de respuestas han entrado en cada uno de los rangos de tiempos de respuesta que serán configurables.

5.27. Se podrán personalizar aplicaciones por:

5.27.1. Puertos

5.27.2. Direcciones de los servidores combinadas con los puertos

5.27.3. URL

5.28. La solución podrá crear roles de usuarios, usuarios y grupos de elementos monitoreados 5.28.1. Se podrá atribuir un grupo de elementos a un usuario para que solo tenga acceso a los elementos monitoreados permitidos.

5.28.2. Cada usuario podrá tener un tamaño de paquete que puede recuperar para observación. El administrador podrá dar visibilidad de paquetes completos a unos usuarios y de paquetes cortados o parciales para otros usuarios.

5.29. Se podrá hacer "drill-down" desde esta interfaz Web hasta una consola de análisis avanzado de aplicaciones que podrá estar como un cliente en el computador de los usuarios.

5.30. En términos de VOIP, la consola WEB podrá entregar reportes de

5.30.1. Volumen de llamadas

5.30.2. Jitter

5.30.3. Packet Loss

5.30.4. MOS Score

5.31. Permitirá usar los paquetes guardados en el almacenamiento de los discos de las sondas para crear "bounce charts que muestren lo paquetes de una conexión y las latencias de estos. Permitirá de una forma liviana observar los paquetes almacenados sin traerlos a la consola.

5.32. Permitirá que el usuario pida salvar la captura en el disco local de su máquina.

5.33. Permitirá graficar KPis para estadísticas selectas donde se puedan ver errores en esas aplicaciones.

5.34. Permitirá crear reportes comparativos entre las interfaces físicas y las interfaces virtuales (subnets, VLAN, QOS) contenidas en las interfaces físicas.

5.35. Permitirá que los usuarios puedan crear grupos de gráficos que una vez aplicadas a una interfaz, puedan ser recreadas fácilmente en otra interfaz como vistas rápidas

 

6. Módulo de Análisis de Sesiones Aplicativas.

6.1. Además de almacenar paquetes, el módulo de captura de tráfico debe generar registros de sesiones aplicativas de al menos:

6.1.1. Citrix

6.1.2. DNS

6.1.3. SMTP

6.1.4. POP3

6.1.5. FTP

6.1.6. http

6.1.7. LDAP

6.1.8. RADIUS

6.1.9. RTP

6.1.10. SIP

6.1.11. H323

6.1.12. Aplicaciones Web personalizadas por el usuario

6.2. Estos registros deberán contener la información relevante de las sesiones de dichos aplicativos y una vez que dicho análisis en lazado sobre un espacio de tiempo, los resultados deberán incluir:

6.2.1. Un selector de tiempo para refinar la búsqueda de sesiones y su análisis.

6.2.2. Un resumen de Clientes del aplicativo

6.2.3. Un resumen de usuarios del aplicativo

6.2.4. Un resumen de errores descubiertos

6.2.5. En el caso de aplicaciones basadas en http, un resumen de URLS

6.2.6. En el caso de aplicaciones basadas en http, un resumen de tipo de browsers usados.

6.2.7. En el caso de DNS el tipo repetición y el nombre implicado, así como la IP resuelta en el caso de transacciones de tipo exitosas

6.3. Los detalles mencionados anteriormente podrán ser usados para filtrar las sesiones.

6.4. Una vez encontrado el foco del análisis se podrá solicitar un listado de las sesiones de interés de forma rápida e integrada en la pantalla del usuario, que deberá ser accedida vía WEB.

6.5. La presentación de las sesiones de los aplicativos deberá ser tal que muestre una "escalera" que muestre los comandos y respuestas de la sesión en cuestión y que entregue una precisión de milisegundos al colocar los elementos de la escalera.

6.6. Para una sesión específica, será posible ya sea salvar los paquetes en caso de que aun estén almacenados en el buffer del módulo de captura o decodificarlos en el mismo caso, directamente en la pantalla del usuario para permitir un análisis inmediato de la información.

6.7. Deberá permitir mostrar el tiempo de respuesta cuando sea posible por medio de columnas que podrán ser adicionadas a los sumarios como cliente o servidor que se han mencionado.

6.8. Varios análisis de este tipo podrán estar presentes en la pantalla del operador del módulo

 

7. Se debe incluir con la propuesta:

7.1. Prever la provisión y montaje de 1 (un) monitor o tv para la visualización constante de la solución:

7.1.1. 60’’ o 65" Full HD como mínimo.

7.1.2. Con entrada HDMI y adaptador para displayPort.

7.1.3. 220 v.

7.1.4. incluir soporte de pared.

8. Soporte técnico 24/7 para toda la solución ofertada ya sea remoto y/o presencial, según necesidad por el periodo de 12 meses sin costo para la Convocante.

 

9. MPLEMENTACIÓN Y TRANSFERENCIA TECNOLÓGICA: 60 horas

A efecto de garantizar la correcta puesta en marcha de la solución, en forma conjunta entre el Proveedor y el Equipo Técnico de la Dirección de TIC’s de la Corte Suprema de Justicia se procederá a la instalación de los componentes que forman parte de la propuesta y su respectiva implementación.

El objetivo principal es transmitir al personal de la institución el conocimiento en el uso de las herramientas tecnológicas para la administración y gestión diaria de la plataforma a implementar. Para ello se propone la modalidad On-Job-Training, este entrenamiento estará a cargo del proveedor y deberá estar dirigido a los técnicos de la TIC.

De esta forma se persigue conformar un equipo de trabajo, con la autonomía suficiente, para operar el servicio en forma integral.

 

10. Términos para tener en cuenta

1. Contar como mínimo con 1 técnico certificado de la marca ofertada.

2. Contar como mínimo con 2 técnicos con certificaciones ITIL para garantizar la buena asistencia en soporte técnico.

3. El proveedor deberá contar con una plataforma y/o sistema de ticket para atención de casos de soporte técnico, a fin de garantizar la respuesta de manera profesional y organizada 24x7.

4. El proveedor deberá tener la Certificación ISO 9001: 2015 Sistema de Gestión de Calidad para garantizar la calidad de sus servicios y la Certificación ISO 27001: 2013 Sistema de Gestión de Seguridad de la Información para garantizar la gestión de la seguridad de la información.

5. El proveedor deberá presentar una carta de autorización del fabricante para la solución del equipo de monitoreo, quedando descartado este requisito para el monitor o TV.

6. Los técnicos certificados deben ser personales dependientes de la Empresa Oferente, se deben acompañar certificados de inscripción en IPS

1- Identificar el nombre, cargo y la dependencia de la Institución de quien solicita el llamado a ser publicado.

Rosa Liz Chamorro Ibarrola, Directora Dirección de Tecnología de la Información y las Comunicaciones

 

2- Justificación de la necesidad

Dicho pedido obedece a que se requiere precautelar la continuidad de nuestros servicios las 24 horas los 365 días del año, tanto de servicios internos como los externos (publicados a través del portal web). Este tipo de servicio es necesario para lograr cumplir con los requisitos de una operación eficiente y sin interrupciones, obteniendo estadísticas que ayuden a ser proactivos en la resolución de los diversos problemas, mejorando así notablemente la performance de la red de datos y por ende el funcionamiento de todos los sistemas corporativos los cuales se encuentran publicados y deben estar disponibles para el usuario 24/7.

 

3- Planificación.

La planificación es por única vez en la adquisición del equipo, sin embargo, el soporte debe ser renovado periódicamente.

 

4- Justificación de las especificaciones técnicas

Las especificaciones técnicas están conformadas de acuerdo con la tecnología requerida por la convocante con la finalidad de monitorear los paquetes de datos y poder visualizar las posibles anomalías a nivel de datos, servicios o servidores mediante sensores para luego tomar acciones rápidas que puedan solucionar problemas de manera eficaz.

Ítem	Descripción del Bien	Cantidad	Unidad de medida	Lugar de entrega de los Bienes	Fecha(s) final(es) de Ejecución de los Bienes
1	EQUIPO DE MONITOREO	1	UNIDAD	Los equipos deben ser entregado instalado y puestos en funcionamiento con toda la transferencia tecnológica necesaria para su óptimo funcionamiento en el Data center de la Dirección General de Tecnología de la Información y Comunicaciones, ubicado en el sub suelo 1 del Palacio de Justicia de Asunción ubicada en las calles Alonso y Testanova, en el horario de 07:30 hs. a 13:00 hs. de lunes a viernes.	El plazo de la entrega, instalación transferencia tecnológica y puesta en funcionamiento es de 90 (noventa) días corridos posteriores a la firma del contrato.

No aplica

No aplica

No aplica

Planificación de indicadores de cumplimiento:

El documento requerido para acreditar el cumplimiento contractual será: Acta de recepción parcial y/o definitiva.

Serán presentados: 1(un) Acta por cada entrega efectuada.

Frecuencia: Conforme se establece en el Plan de Entrega de bienes establecido en el PBC.

 

INDICADOR	TIPO	FECHA DE PRESENTACIÓN PREVISTA (se indica la fecha que debe presentar según el PBC)
Acta de Recepción Parcial y/o definitiva.	Acta	Hasta 90 (noventa) días corridos, computados a partir de la fecha de la firma del contrato

La Convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

 

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.