ST/SE Licitación Abreviada: Adquisición de software de observabilidad para gestión y monitoreo integral de servicios tecnologías de información - según demanda

a) El oferente deberá presentar las declaraciones juradas y certificaciones establecidas en el Anexo de Declaraciones Juradas y certificaciones.
b) El oferente debe presentar una declaración jurada o certificación que acredite su relación comercial con el proveedor de nube pública o el fabricante donde se despliega el software ofrecido, en la que se le reconozca que ostenta la categoría o nivel más alto del programa de canales o de alianzas comerciales (Partner Tier) establecido por dicho fabricante, como experto en la solución propuesta para su distribución y soporte técnico. Asimismo, dicha certificación debe indicar que el oferente cuenta con tres (3) años de experiencia comprobable como distribuidor autorizado, respaldando su capacidad en la administración, operación y soporte integral de la solución.
En aquellos casos donde el fabricante utilice una nomenclatura distinta, el oferente deberá demostrar que la certificación o declaración jurada presentada equivale a la categoría o al nivel más alto establecido por el fabricante.
La certificación deberá haber sido emitida en los tres (3) meses anteriores respecto a la fecha de apertura de las ofertas. La Administración no aceptará documentos firmados por vendedores o encargados de cuenta de empresas distribuidoras.
c) El oferente deberá presentar una carta emitida por el fabricante donde se haga constar que es distribuidor autorizado de la plataforma ofertada. La Administración podrá verificar la autenticidad del documento por medios electrónicos o solicitar el original cuando lo considere pertinente.

d) Experiencia del oferente.
1. El oferente deberá presentar una declaración jurada en la que indique que cuenta con experiencia de tres (3) proyectos de aprovisionamiento de soluciones en la nube de la plataforma ofertada. Estos proyectos deben haber sido debidamente implementados y recibidos a satisfacción dentro de los tres (3) años previos a la fecha establecida para la apertura de las ofertas.
2. A tal efecto, el oferente deberá presentar una declaración jurada que incluya la lista de los clientes a quienes les haya brindado directamente los servicios antes mencionado, detallando:
i. Nombre del cliente.
ii. Descripción del servicio realizado.
iii. Plataforma implementada.
iv. Dirección.
v. Teléfono del cliente.
vi. Correo electrónico del cliente.
vii. Fecha (mes/año) de inicio y finalización cuando se realizó el proyecto.
viii. Nombre contacto del cliente.
ix. Indicación expresa si durante la ejecución contractual se le aplicaron multas y los motivos por los cuales fueron multados.

3. El ICE se reserva el derecho de verificar los datos consignados en la lista y en caso de identificar alguna inconsistencia en dichos datos o que no se pueda verificar la veracidad de los hechos referenciados primero se solicitará una aclaración al oferente y si posterior a la aplicación de todos los mecanismos anteriores (consulta a los clientes mencionadas y aclaraciones al oferente) y la Administración no pueda confirmar la veracidad de los hechos referenciados no se podrá tomar en cuenta el proyecto citado por el oferente y se dará por incumplido el requisito de admisibilidad.
4. Como parte de los servicios requeridos en el cartel, el oferente deberá disponer de tres (3) profesionales especializados, dos (2) técnicos especializados y un (1) administrador de proyectos con el fin de asegurar el correcto funcionamiento de la solución propuesta, a continuación, se enlista los requisitos que deben cumplir para cada personal indicado.
Condiciones generales para los perfiles requeridos

4.1 Datos del personal: El oferente debe consignar en la oferta los datos del personal: nombre, nacionalidad, profesión, centro educativo donde realizo su formación, título obtenido, grado académico obtenido, tiempo de trabajar para la empresa. Un mismo recurso no podrá compartir más de un rol.
4.2 Perfil curricular: El oferente debe incluir el currículo del personal que brindará los servicios de soporte e implementación de los servicios contratados, de la plataforma ofertada.
4.3 Atestados: El oferente debe suministrar al ICE los atestados y documentación pertinente que respalden la experiencia, así como la trayectoria académica y profesional del personal propuesto, tales como títulos académicos, certificaciones, constancias de experiencia laboral y cualquier otro documento que demuestre su idoneidad para la prestación del servicio.
Detalle de los perfiles requeridos:
4.4 Personal Profesional Especializado
4.4.1 Tres (3) profesionales debidamente certificados en la plataforma ofertada.
4.4.2 Requisitos académicos del profesional:
i. El personal profesional referenciado en la oferta debe tener el grado académico de Bachiller, en alguna de las siguientes ramas: Sistemas de Información, Electrónica, Eléctrica, Informática, Computación o afín, extendido por cualquier Centro de Educación reconocido por el Ministerio de Educación de Costa Rica o su equivalente internacionalmente, para lo cual deben presentar copia del título debidamente certificado o autenticado.
ii. Dos (2) de los 3 profesionales referenciado en la oferta deben cumplir con el marco de trabajo de SCRUM.
iii. El oferente deberá presentar copia de certificaciones vigentes emitidas por el fabricante de la plataforma de observabilidad propuesta, en las cuales se acredite que el personal profesional propuesto ha completado con éxito la prueba de certificación correspondientes. Dichas certificaciones deberán reflejar el perfil del profesional y acreditar un nivel igual o superior a Professional (o su equivalente, entendiéndose este último como certificaciones de nivel intermedio o avanzado dentro de la ruta oficial del fabricante, que validen conocimientos en implementación, configuración y operación de la solución), y haber sido emitidas dentro de los tres (3) años previos a la fecha de presentación de la oferta.
iv. Las certificaciones de los profesionales en la plataforma, no pueden ser certificaciones de ventas.

4.4.3 Respecto a la experiencia:
i. Cada profesional referenciado en la oferta, debe haber implementado y configurado tres (3) proyectos de la plataforma ofertada o similares dentro de los tres (3) años anteriores a la fecha fijada para la apertura de ofertas, los cuales deben estar debidamente implementados y productivos. A tal efecto, el oferente debe aportar una declaración jurada con la lista de los clientes a los cuales cada profesional les brindó directamente los servicios antes citados, detallando:
• Nombre del cliente.
• Descripción del servicio realizado.
• Dirección.
• Teléfono del cliente.
• Correo electrónico del cliente.
• Fecha (mes/año) de inicio y finalización cuando se realizó el proyecto.
• Nombre contacto del cliente
• Indicación expresa si durante la ejecución contractual se le aplicaron multas y los motivos por los cuales fueron multados

4.4.4 El personal profesional referenciado en la oferta podrá estar ubicado fuera del territorio costarricense; sin embargo, deberá contar con disponibilidad conforme a la zona horaria de Costa Rica (UTC-06:00), ya que esta será la utilizada para programar las sesiones de seguimiento del proyecto.

4.4.5 El ICE se reserva el derecho de verificar los datos consignados en la lista y en caso de identificar alguna inconsistencia en dichos datos o que no se pueda verificar la veracidad de los hechos referenciados primero se solicitará una aclaración al oferente y si posterior a la aplicación de todos los mecanismos anteriores (consulta a los clientes mencionadas y aclaraciones al oferente) y la Administración no pueda confirmar la veracidad de los hechos referenciados no se podrá tomar en cuenta el proyecto citado por el oferente y se dará por incumplido, se reserva el derecho de verificar los datos consignados en la lista y en caso de no ser correctos los mecanismos señalados previstos para ubicar el contacto, no se tomará la referencia que no haya sido verificada para efectos de cumplir con el requisito de admisibilidad.

4.5 Personal Técnico Especializado:
4.5.1 Dos (2) técnicos debidamente certificados en la plataforma ofertada.
4.5.2 Requisitos académicos del técnico solicitado:
i. El personal técnico especializado referenciado en la oferta deberá tener el grado académico de Técnico Medio, en alguna de las siguientes ramas: Sistemas de Información, Electrónica, Eléctrica, Informática, Computación o afín extendido por cualquier Centro de Educación reconocido por el Ministerio de Educación de Costa Rica o su equivalente internacionalmente.
ii. El oferente deberá presentar copia de las certificaciones vigentes emitidas por el proveedor de la solución, en las que se indique el perfil del técnico propuesto. Dichas certificaciones deberán acreditar un nivel igual o superior a Associate y haber sido emitidas, dentro de los dos (2) años previos a la fecha de entrega de la oferta.
iii. Las certificaciones de los técnicos en la plataforma, no pueden ser certificaciones de ventas.

4.5.3 Experiencia:
i. Cada técnico referenciado en la oferta, dentro de los últimos tres (3) años anteriores a la fecha fijada para la apertura de ofertas, debe haber participado y configurado tres (3) proyectos de aprovisionamiento de soluciones en nube de la plataforma ofertada. A tal efecto, el oferente deberá presentar una declaración jurada que incluya una lista de los clientes a los cuales les brindó directamente los servicios antes citados; detallando al menos:
• Nombre del cliente.
• Descripción del servicio realizado.
• Dirección.
• Teléfono del cliente.
• Correo electrónico del cliente.
• Fecha (mes/año) de inicio y finalización cuando se realizó el proyecto.
• Nombre contacto del cliente
• Indicación expresa si durante la ejecución contractual se le aplicaron multas y los motivos por los cuales fueron multados

4.5.4 El personal técnico referenciado en la oferta podrá estar ubicado fuera del territorio costarricense; sin embargo, deberá contar con disponibilidad conforme a la zona horaria de Costa Rica (UTC-06:00), ya que esta será la utilizada para programar las sesiones de seguimiento del proyecto.

4.5.5 El ICE se reserva el derecho de verificar los datos consignados en la lista y en caso de identificar alguna inconsistencia en dichos datos o que no se pueda verificar la veracidad de los hechos referenciados primero se solicitará una aclaración al oferente y si posterior a la aplicación de todos los mecanismos anteriores (consulta a los clientes mencionadas y aclaraciones al oferente) y la Administración no pueda confirmar la veracidad de los hechos referenciados no se podrá tomar en cuenta el proyecto citado por el oferente y se dará por incumplido, se reserva el derecho de verificar los datos consignados en la lista y en caso de no ser correctos los mecanismos señalados previstos para ubicar el contacto, no se tomará la referencia que no haya sido verificada para efectos de cumplir con el requisito de admisibilidad.

4.6 Administrador de proyectos:
4.6.1 Un (1) administrador de proyectos.
4.6.2 Requisitos académicos del administrador de proyectos solicitado:
El administrador de proyectos debe contar con el título de Bachiller universitario en alguna de las siguientes ramas: Ciencias Económicas y Administrativas, Informática, Computación o Ingeniería, extendido por cualquier Centro de Educación reconocido por el Ministerio de Educación Pública de Costa Rica, para lo cual, deben presentar fotocopia del título debidamente certificado.
4.6.3 Certificaciones:
i. Debe de contar y presentar como parte de la oferta la certificación PMP (Project Management Professional), emitida por el PMI (Project Management Institute), o bien con el título académico de máster con énfasis en Administración de Proyectos.
ii. Debe contar y presentar como parte de la oferta la certificación SCRUM Master vigente.

4.6.4 Experiencia:
4.6.4.1 El administrador de proyectos referenciado en la oferta debe tener experiencia en la ejecución de un (1) proyecto el cual tuvo que haber sido ejecutado dentro de los dos (2) años anteriores a la fecha de apertura de las ofertas.
4.6.4.2 A tal efecto, el oferente deberá presentar una declaración jurada que incluya una lista de o los clientes a quienes haya brindado directamente los servicios antes citados, detallando:
• Nombre del cliente.
• Descripción del servicio realizado.
• Dirección.
• Teléfono del cliente.
• Correo electrónico del cliente.
• Fecha (mes/año) de inicio y finalización cuando se realizó el proyecto.
• Nombre contacto del cliente
• Indicación expresa si durante la ejecución contractual se le aplicaron multas y los motivos por los cuales fueron multados.

ESPECIFICACIONES TÉCNICAS

1. Objeto contractual
Adquisición de un software de observabilidad para la gestión y monitoreo integral de los servicios de aplicaciones, microservicios, bases de datos, componentes de red y experiencia de usuario asociados a tecnologías de información, incluyendo trazabilidad, métricas, registros y demás capacidades de observabilidad, conformando en conjunto todos estos componentes una plataforma de observabilidad y monitoreo (procedimiento según demanda)
Esta plataforma permitirá el análisis, diagnóstico y optimización del rendimiento de aplicaciones y servicios, permitiendo funciones clave como el monitoreo en tiempo real, la detección y diagnóstico de incidentes, la trazabilidad de transacciones, el análisis de registros y eventos, así como la generación de alertas proactivas y de igual manera, deberá ofrecer capacidades de escalabilidad y soporte multiplataforma, por un período de 12 (doce) meses, prorrogables por 3 (tres) periodos de igual duración.

2. REQUERIMIENTOS TÉCNICOS GENERALES:
2.1. La plataforma de monitoreo y observabilidad deberá contar con capacidades habilitadas para supervisar sistemas operativos, bases de datos, servidores de aplicación, gestión y almacenamiento de logs, automatizaciones, servicios, middleware, vulnerabilidades a nivel aplicativo, contenedores y sus orquestadores. Asimismo, deberá permitir el monitoreo de aplicaciones, servicios de integración, entornos de virtualización, frameworks de desarrollo y sistemas de almacenamiento, todo integrado en una misma plataforma. Esta, a su vez, deberá incorporar un motor de inteligencia artificial nativo que garantice la observabilidad integral de los servicios, la infraestructura y las aplicaciones del ICE.
2.2. La plataforma de monitoreo y observabilidad, deberá operar totalmente desde la nube pública o del fabricante, de manera que no tenga dependencias para su funcionamiento implementadas por cada sitio, en caso de tener la necesidad de utilizar agentes propios de la solución, la captura de eventos se deberá de realizar en los servidores del ICE y la plataforma que aprovisiona el software de monitoreo y observabilidad también deberá estar en la nube pública o del fabricante.
2.3. El contratista podrá adquirir la plataforma a través del marketplace de las nubes públicas utilizadas por el ICE. En este caso, el contratista será responsable de la facturación derivada de la oferta en el marketplace de la nube definida, con el fin de aprovisionar el ambiente SaaS y asignarlo a la cuenta empresarial del ICE. Esta modalidad de adquisición será válida únicamente cuando la solución pueda distribuirse por dicho medio y se garantice lo mencionado en el punto anterior.
2.4. La plataforma deberá contar con la flexibilidad para que el ICE pueda migrar el monitoreo de un servidor a otro (con los mismos recursos asociados), basado en sus prioridades y necesidades cambiantes, sin que exista un costo adicional por ello.
2.5. La plataforma no deberá ser restrictiva y deberá contar con la capacidad de monitorear servicios expuestos, incluyendo aquellos correspondientes a sistemas tercerizados, para asegurar la integración con los sistemas del ICE.
2.6. La plataforma no deberá requerir el establecimiento de canales directos de transmisión de información desde los equipos monitoreados hacia internet. Lo anterior debido a las restricciones de acceso a Internet que tienen de los equipos monitoreados para garantizar su seguridad.
2.7. La recopilación de datos de telemetría (MELT) deberán enviarse a la plataforma en la nube a través de colectores virtuales a los cuales los agentes de monitoreo deberán conectarse automáticamente, con la capacidad de trabajar de manera conjunta para distribuir el tráfico de la telemetría enviada a dicha plataforma.
2.8. Los agentes de recolección de datos de telemetría deberán ser capaces de dirigir automáticamente el tráfico hacia los colectores disponibles, priorizando la zona de red a la cual este asignado.
2.9. El contratista deberá garantizar la corrección de cualquier defecto de programación de la plataforma de observabilidad y monitoreo por parte del fabricante; ya sea de la versión vigente de la plataforma en el momento de adjudicación o cualquier otra que este contrato ampare.

2.10. Seguridad y Protección de Datos
2.10.1. El contratista garantizará por medio de mecanismos de software el cifrado de datos en tránsito y en reposo.
2.10.2. El tráfico de datos debe ser cifrado mediante TLS 1.2.
2.10.3. Autenticación federada (LDAP, OAuth 2.0).
2.10.4. Control de acceso basado en roles (RBAC).
2.10.5. Auditoría y trazabilidad de cambios en la configuración.

2.10.6. La plataforma debe cumplir con los estándares internacionales de seguridad de la información (ISO 27001, SOC 2, cifrado AES-256).

2.11. Compatibilidad y accesibilidad
2.11.1. La plataforma deberá ser 100 % accesible en forma web, soportando los siguientes navegadores, en la última versión de cada uno al momento de la adjudicación del cartel, así como las versiones aún soportadas por el fabricante:
• Microsoft Edge
• Mozilla Firefox
• Google Chrome
• Safari
2.11.2. La plataforma deberá contar con una aplicación móvil o PWA (Progressive Web Application), que permita tener acceso 24x7x365 a la plataforma, capaz de notificar problemas (notificaciones push) según el rol del usuario que la utiliza y soportando los siguientes sistemas operativos móviles en la última versión de cada uno al momento de la adjudicación, así como las versiones aún soportadas por el fabricante):
• Android
• iOS
2.11.3. La plataforma deberá soportar el monitoreo de los siguientes sistemas operativos:
• Windows Server, versiones del 2012 R2 en adelante (hasta la última versión al momento de la notificación del contrato en firme en SICOP.
• Linux, distribuciones RHEL 7 en adelante, Ubuntu 18 en adelante, Debian 10 en adelante, Oracle Linux 7 en adelante.
• Se aclara que deberá estar habilitado para monitorear los sistemas operativos mencionados anteriormente y, además, el agente deberá poder instalarse en estos sistemas operativos.
• En caso de que el sistema operativo no sea soportado, deberá ser posible monitorearse a través de integraciones como SNMP o con uso de agentes abiertos como OpenTelemetry.

2.11.4. La plataforma y sus agentes deberán ser compatibles e integrables con herramientas estándar de monitoreo:
• OpenTelemetry
• Prometheus
• Fluent Bit
• Fluentd
• Logstash
2.11.5. La plataforma deberá soportar el monitoreo de las siguientes tecnologías de red:
• TCP/IP v4
• TCP/IP v6
• WMI
2.11.6. La plataforma deberá soportar el monitoreo de los siguientes protocolos de red:
• Netflow
• SNMP v2c/v3
• http/https
• ftp/sftp
2.11.7. La plataforma deberá soportar el monitoreo completo, de las plataformas de virtualización utilizadas por el ICE:
• VMware
• QEMU
• KVM
• Hyper-V
• Amazon Web Services (AWS)
• Microsoft Azure
2.11.8. La plataforma deberá soportar el monitoreo completo de los motores de bases de datos utilizadas por el ICE:
• MS SQL Server, versiones soportadas por el fabricante (incluso las extended support),
• Oracle Database, versiones soportadas por el fabricante (incluso las extended support),
• MySQL, versiones soportadas por el fabricante (incluso las extended support),
• MariaDB, versiones soportadas por el fabricante (incluso las extended support).

2.11.9. La plataforma deberá soportar el monitoreo de las siguientes tecnologías .Net:
• Net Framework, versiones soportadas por el fabricante (incluso las extended support)
• Frameworks web y servicios web
• ASP.NET
• ASP.NET Core, versiones soportadas por el fabricante (incluso las extended support)
• WCF (incluidos los protocolos net.tcp y http)
• ASMX
• Service Fabric Reliable Services, versión 2.5
• HttpClient
• Framework de base de datos ADO.Net, Entity Framework 4.0 hasta la versión 6.1.2
• Entity Framework Core, versiones soportadas por el fabricante (incluso las extended support) 1.0, 2.0 y 2.1

2.11.10. La plataforma deberá soportar el monitoreo de las siguientes tecnologías de servidores web:
• Microsoft IIS, versiones soportadas por el fabricante (incluso las extended support).
• IHS (IBM HTTP Server) versión 9.0.5.x
• Apache HTTP Server, Apache TOMCAT
• Nginx

2.11.11. La plataforma deberá soportar el monitoreo de las siguientes plataformas de middleware:
• WAS (Websphere Application Server) versión 9.0.5.x
• IBM WebSphere Liberty, versión 25.0.0.1
• Oracle Weblogic Server

2.11.12. La plataforma deberá soportar el monitoreo de los siguientes buses de integración:
• IBM Integration Bus
2.11.13. La plataforma deberá soportar el monitoreo de las siguientes colas de mensajes:
• IBM MQ.
• RabbitMQ.
• Kafka.
2.11.14. La plataforma deberá tener capacidad de monitorear las aplicaciones que el ICE ejecute en los entornos de orquestación de contenedores y deberá cumplir con los siguientes requisitos:
• Poseer la capacidad para monitorear contenedores en clúster con Kubernetes (RKE & VKS) en una visualización detallada basada en la jerarquía de componentes de nativos (Nodos, Namespaces, Workloads, Daemonsets, StatefulSets, Deployments, ReplicaSets, Jobs, Pods, Containers, Services, Operators, etc.).
• Habilitar el descubrimiento automático de nodos y contenedores según sus identificadores únicos o nombres de host.
• Entregar una visualización completa de métricas, eventos y salidas de consola de los contenedores (logs) así como los recursos de la infraestructura donde corre cada nodo del clúster (CPU, memoria dinámica RAM, espacio en disco, tráfico de red, etc.).
• Proveer soporte para las prácticas de GitOps asociadas a la configuración de monitoreo como código.
• Proveer una configuración prediseñada de alertas para Kubernetes.
• Ser capaz de configurarse en servicios de Kubernetes como servicio en nube.

2.11.15. La plataforma deberá proveer un detalle de los procesos que ejecuta cada pod y sus contenedores asociados dentro del clúster.
2.11.16. La plataforma deberá ser no intrusivo y agnóstico a los contenedores. Esto se refiere a la capacidad de obtener información de estos sin requerir configuraciones específicas de los aplicativos o ajustes a las imágenes que se ejecutan en el clúster.
2.11.17. La plataforma deberá proveer un modelo de gestión basado en el autodescubrimiento de componentes y cargas de trabajo.
2.11.18. La plataforma deberá proveer un seguimiento del tráfico de red del clúster, tanto a nivel interno como externo y que permita la identificación de problemas y fallos en las solicitudes (request).
2.11.19. La plataforma deberá contar con herramientas de análisis de seguridad integrado para la identificación de vulnerabilidades, detección de ataques y herramientas similares que ayuden a los equipos a mejorar la seguridad de las aplicaciones y los clústeres en general.

2.12. Descubrimiento automático
2.12.1. La plataforma deberá realizar un descubrimiento automático y de forma continua de los siguientes componentes:
• Servidores virtuales y físicos On-Premise (desplegados en los centros de datos del ICE).
• Servidores virtuales accedidos como servicio en la nube.
• Servidores virtuales y físicos, configurados en esquemas de alta disponibilidad (clúster, granjas, etc.).
• Procesos.
• Servicios.
• Bases de datos.
• Logs en cada host y externos.
• Red de los servidores (interfaces de red).
• Dependencias y relaciones entre componentes tecnológicos.
• Virtualización On-Premise y Cloud (VMware, Hyper-V, Amazon EC2, etc.).
• Contenedores.
• Microservicios.
• Tecnologías aplicativas (Java, .NET, Node.js, PHP, etc.).
• Código.
• Base de Datos y sentencias SQL.
• Experiencia de usuarios reales y sus acciones.
• Cada transacción individual.
• Aplicaciones web
• Aplicaciones de terceros (cualquier servicio externo fuera de la infraestructura del ICE que sea llamado desde las aplicaciones monitoreadas).

2.12.2. Dada la necesidad de incluir todos los componentes tecnológicos en los análisis de causa raíz, la plataforma deberá tener la capacidad de generar, en forma automática y continua, un esquema gráfico de todas las relaciones entre dichos componentes, a partir de los servidores monitoreados por la solución.
2.12.3. La plataforma de monitoreo deberá tener la capacidad de detectar y mapear dependencias en tiempo real y de manera automática e integral de todos los componentes en modo Full stack antes mencionados.
2.12.4. La plataforma deberá sugerir en forma automática y continua, aquellos servidores considerados candidatos para ser monitoreados, en caso de que tengan alguna interacción con las aplicaciones o servidores monitoreados. Esto permitirá descubrir cualquier relación con elementos críticos de la aplicación, que haya sido omitida en el monitoreo actual.
2.12.5. La plataforma deberá permitir la creación y correlación de los servicios basados en el nombre servidores, procesos, servicios y dominios de cada aplicación en forma automática. Estos objetos pueden ser modificados o reasignados en cualquier momento por el administrador, con el objetivo de seguir los estándares y nomenclatura del ICE.
2.12.6. La plataforma deberá crear y actualizar umbrales base del comportamiento de las aplicaciones, servicios, procesos y recursos de infraestructura descubiertos, de manera automática y continua, permitiendo basar el monitoreo en el comportamiento normal de las aplicaciones, evitando así la detección de falsos positivos.
2.12.7. La plataforma deberá permitir la segmentación de los componentes tecnológicos según los estándares del ICE, por ejemplo: Servidores de Producción, Servidores de Desarrollo, Servidores de Pruebas, entre otros.
2.12.8. La plataforma deberá mostrar un “gráfico de relaciones” de forma automática y continua, de todos los componentes tecnológicos descubiertos, incluyendo los hosts, procesos, servicios, aplicaciones, de manera tal que sea rápida y sencilla la identificación de dependencias en un entorno tecnológico complejo y heterogéneo como el del ICE.
2.12.9. La plataforma deberá permitir búsquedas en el gráfico de relaciones, de cualquier tipo de componente de software, mostrando todos los elementos relacionados con el componente seleccionado.
2.12.10. La Inteligencia artificial deberá ser capaz de analizar de manera automática ante una situación crítica, lo siguiente:
• Experiencia de usuario reales (Impacto).
• Topología (Mapa de dependencias de las aplicaciones).
• Transacciones (end to end).
• Nivel de código.
• Vulnerabilidades.
• Plataformas Cloud.
• Infraestructura.
• Servicios.
• Procesos.
• Eventos / Alarmas de las aplicaciones y servicios monitoreadas.
• Logs de las aplicaciones.

2.13. Gestión de la plataforma
2.13.1. La plataforma deberá tener grupos de usuarios predefinidos, con privilegios asignados para diversos roles de monitoreo, y deberá permitir crear grupos adicionales según sea necesario.
2.13.2. La plataforma deberá definir de forma automática e inteligente, los criterios para la definición de problemas e incidentes, considerando las métricas históricas, las líneas base de los componentes monitoreados, además de heurísticas que permitan analizar y determinar la causa raíz más probable de problemas comunes.
2.13.3. La plataforma deberá permitir la definición manual de umbrales para que sean utilizados en la definición de problemas e incidentes, considerando las siguientes métricas: CPU, memoria, disco, transmisión de red, retransmisión de red, tiempo de respuesta de la aplicación, tasa de falla de la aplicación, duración de las acciones de los usuarios, tiempo de respuesta de las bases de datos, tasa de fallas de las bases de datos.
2.13.4. La plataforma deberá realizar la notificación de problemas por: email, Teams, webhooks, notificaciones a la aplicación móvil, o por medio de la integración con el ITSM utilizado por el ICE para la apertura de casos correspondientes, lo cual permitirá mantener en tiempo real, la notificación y pronta atención de incidentes que afecten la experiencia de usuario en las aplicaciones.
2.13.5. La plataforma deberá contar con una API HTTP Restful, por medio de la cual permita la extracción de datos para integrarla con otros sistemas.
2.13.6. La plataforma deberá permitir la creación de dashboard personalizados para recolectar y monitorear métricas específicas y definidas por el cliente (por ejemplo, número de conexiones abiertas en un determinado servidor).
2.13.7. Con el objetivo de acelerar el proceso de configuración y entrega, la plataforma deberá permitir la creación lógica de reglas de agrupamiento de servicios, procesos y aplicaciones, permitiendo la identificación de esquemas de alta disponibilidad.
2.14. Requerimientos de monitoreo y observabilidad de aplicaciones
2.14.1. La plataforma no deberá requerir cambios en las aplicaciones web, servicios, procesos, y sistemas operativos, para realizar el monitoreo solicitado.
2.14.2. La plataforma deberá permitir almacenar las métricas recolectadas (relacionadas a eventos o problemas) por un periodo de un (1) año.
2.14.3. La plataforma deberá realizar en forma automática y continua, el análisis del rendimiento y comportamiento de los usuarios finales en las aplicaciones web, por ejemplo: .Net, Java, javascript, entre otros; permitiendo la auto detección de nuevas aplicaciones.
2.14.4. La plataforma deberá realizar en forma automática y continua, la recolección de información sobre las acciones de los usuarios en las aplicaciones web y móviles, mostrando en una línea continua de tiempo, las siguientes métricas: cantidad de acciones, la duración promedio de las acciones, el tiempo de las acciones más lentas y rápidas.
2.14.5. La plataforma deberá mostrar mediante gráficos automáticos, información en tiempo real de: la cantidad de acciones de los usuarios, duración promedio y cantidad de solicitudes por unidad de tiempo para cada una de las aplicaciones web o móviles monitoreadas.
2.14.6. La plataforma deberá realizar la comparación de esta información con datos históricos, por ejemplo, con datos de la semana anterior, mes anterior, año anterior, etc. potenciando el uso de IA para la detección de anomalías con base en ese comportamiento histórico.
2.14.7. La plataforma deberá mostrar en forma automática y continua, información sobre eventos ocurridos en la aplicación, como los "reinicios" o "actualizaciones (release)" en los servidores monitoreados entre otros eventos, permitiendo así la correlación de incidentes con estas acciones.
2.14.8. La plataforma deberá ser capaz de calendarizar momentos de indisponibilidad, para no afectar el SLO cuando se tratase de mantenimientos programados que impacten la disponibilidad de los aplicativos.
2.14.9. Para brindar un mayor nivel de detalle en el diagnóstico de problemas e identificación de mejoras en el comportamiento de las aplicaciones, la plataforma deberá mostrar en forma automática y continua, un resumen de todas las acciones de usuario de una aplicación, incluyendo la siguiente información:
• Cantidad total de las solicitudes ejecutadas por unidad de tiempo.
• Cantidad de errores observados por unidad de tiempo.
• Duración promedio de cada acción.

2.14.10. La plataforma deberá permitir analizar cuál es el tiempo de espera de servicios de terceros que son invocados desde las aplicaciones, incluyendo servicios web (web services, wcf), imágenes, videos, entre otros. Estos valores permitirán identificar posibles causas raíz para problemas relacionados con tiempos de espera en las aplicaciones monitoreadas causadas por terceros.
2.15. Transacciones y servicios
2.15.1. La plataforma deberá identificar en forma automática y continua, los servicios que se encuentran en ejecución en el servidor monitoreado, realizando agrupaciones según criterios preestablecidos, permitiendo su modificación por parte de los usuarios asignados por el ICE en caso necesario, acelerando así el proceso de configuración y ajuste de la solución, acortando las fechas para la entrega de resultados.
2.15.2. Con el objetivo de realizar el análisis de comportamiento de las capas intermedias de servicios y obtener insumos en los ciclos de mejora continua de las aplicaciones, la plataforma deberá monitorear el rendimiento de los servicios en ejecución en el servidor monitoreado, indicando: la tasa de falla, solicitudes por minuto y tiempo de respuesta promedio.
2.15.3. La plataforma deberá indicar las aplicaciones y demás servicios que consumen cada uno de los servicios monitoreados, así como aquellos servicios y bases de datos utilizados, es decir, la solución deberá analizar y mostrar en forma gráfica las entradas y salidas de cada servicio.
2.15.4. La plataforma deberá registrar el 100 % de las transacciones de los usuarios y servicios. No deberá hacer un muestreo de estas.
2.15.5. La plataforma deberá registrar y mostrar las clases y métodos de código involucrados en las transacciones de los usuarios y servicios (cuando el lenguaje de programación así lo permita).
2.15.6. La plataforma deberá mostrar un gráfico de la cantidad de transacciones, distribuidos por rangos de tiempo, permitiendo el análisis del comportamiento, para identificar las frecuencias, máximos, mínimos, moda y concentraciones de los tiempos de respuesta de dichas transacciones.
2.15.7. Para cada servicio y método identificado, la plataforma deberá mostrar gráficamente los tiempos de respuesta, la tasa de fallas y utilización de CPU, de manera tal que puedan identificarse cuellos de botella, comportamientos anormales y oportunidades de mejora.
2.15.8. Para cada servicio y método identificado, la plataforma deberá detallar el tiempo de respuesta. Este tiempo deberá poder ser segregado por tiempo de servidor, tiempo de red y tiempo de la base de datos, tiempo de recolector de basura, tiempo de aplicaciones de terceros, tiempo de acceso al almacenamiento.

2.16. Bases de datos
2.16.1. La plataforma deberá realizar el análisis de todas las llamadas a la base de datos hechas por los componentes de aplicación. Para eso, no deberá ser necesario instalar agentes en el servidor de base de datos, ni contar con un usuario y contraseña de conexión a la base de datos. Estos registros de llamadas a base de datos permitirán considerar sus tiempos de respuesta como parte de las estadísticas de la aplicación, siendo insumos para identificación y diagnóstico de causa raíz en los problemas.
2.16.2. Para las conexiones a la base de datos, la plataforma deberá permitir observar la tasa de fallas, tiempo de respuesta promedio y la cantidad de solicitudes en el rango de tiempo seleccionado.
2.16.3. La plataforma deberá mostrar el listado de las consultas más lentas a las bases de datos, indicando sus tiempos de respuesta y la cantidad de solicitudes en el rango de tiempo seleccionado.
2.16.4. Para todas las consultas a las bases de datos, la plataforma deberá informar el número de filas retornadas, así como el tiempo de respuesta.
2.16.5. Para todas las consultas a la base de datos, la plataforma deberá mostrar un gráfico de distribución de los tiempos de respuesta versus la cantidad de ocurrencias, permitiendo así que sea posible identificar los tiempos de respuesta más prolongados durante el análisis.
2.16.6. Para todas las sentencias hacia la base de datos, la plataforma deberá indicar los tipos de sentencias más ejecutadas (modificación o consulta), cantidad registrados por unidad de tiempo, el tiempo medio de respuesta, así como el detalle las sentencias.
2.16.7. A partir de una sentencia de base de datos, la plataforma deberá mostrar la lista de los métodos, aplicaciones y/o servicios que la ejecutaron.
2.16.8. Permitir el monitoreo de consultas personalizadas, así como la opción de creación de gráficos, reportes y alertas a partir de ellas.
2.16.9. La plataforma deberá mostrar las sentencias a bases de datos de mayor consumo e impacto sobre esta, de forma completamente automática y sin necesidad de configuración adicional al descubrir y analizar las consultas sobre las bases de datos.
2.17. Monitoreo de Servidores físicos y virtuales (Hosts)
2.17.1. La plataforma deberá monitorear para cada servidor físico o virtual soportado del ICE, el consumo de CPU, memoria, tráfico de red, conectividad y retransmisión a lo largo del tiempo de monitoreo. El ICE requiere que cada una de las transacciones ejecutadas por los usuarios en las aplicaciones, sea correlacionada en forma automática y continua, con el estado y comportamiento de la plataforma de hardware, esto con el objetivo de mantener y favorecer la identificación y diagnóstico de causas raíz.
2.17.2. La plataforma deberá mostrar el porcentaje de disponibilidad del servidor calculado para la ventana de tiempo de evaluación seleccionada. El usuario podrá definir el rango temporal específico para la visualización de los datos, permitiendo medir la disponibilidad y auditar todos los procesos, problemas y eventos ocurridos durante ese periodo determinado..
2.17.3. La plataforma deberá mostrar, para cada uno de los procesos que se ejecutan en el servidor, el tipo de proceso, consumo promedio de CPU, memoria y tráfico de red. Estas últimas métricas deben estar disponibles para ser analizadas en detalle en una distribución a lo largo del tiempo.

2.18. Redes
2.18.1. lLa plataforma deberá realizar en forma automática y continua, un monitoreo del comportamiento de las comunicaciones en los servidores monitoreados, recolectando y mostrando, la tasa de tráfico, disponibilidad de los servidores y tasa de retransmisión.El ICE requiere que cada una de las transacciones ejecutadas por los usuarios en las aplicaciones, sean correlacionadas en forma automática y continua, con el estado y comportamiento de la plataforma de red, esto con el objetivo de mantener y favorecer la identificación y diagnóstico de causas raíz.
2.18.2. La plataforma deberá mostrar las métricas de tráfico, disponibilidad y tasa de retransmisión para cada uno de los grupos de proceso identificados, servidores y tarjetas de red (físicas y virtuales) del entorno de monitoreo.
2.18.3. La plataforma deberá contar con una vista en donde pueda observarse el resumen del tráfico de red de entrada y de salida de toda la infraestructura monitoreada, por servidor, tarjeta de red y proceso.
2.19. Mapa de las tecnologías usadas en los sistemas
2.19.1. Con el objetivo de llevar un control del ecosistema monitoreado, así como un registro y clasificación de los incidentes, problemas y aplicaciones, la plataforma deberá crear en forma automática y continua una vista gráfica y estructurada de todas las tecnologías existentes en el entorno monitoreado, permitiendo identificar además de las tecnologías, el tipo y la cantidad de componentes de cada una.
2.20. Virtualización
2.20.1. La plataforma deberá para cada una de las transacciones ejecutadas por los usuarios en las aplicaciones, mantener la correlación en forma automática y continua, con el estado y comportamiento de la plataforma de virtualización, esto con el objetivo de mantener y favorecer la identificación y diagnóstico de causas raíz. La plataforma deberá permitir la integración con plataformas de virtualización empresarial.
2.20.2. La plataforma deberá mostrar métricas de rendimiento de la plataforma, por ejemplo: cantidad de máquinas virtuales encendidas, apagadas o en "stand by", número de migraciones diarias, utilización de CPU, memoria, latencia de disco, consumo de red. Además, deberá permitir que mediante la navegación en la interfaz gráfica se pueda mostrar cuáles son los componentes causantes de dicho comportamiento, según el recurso o métrica seleccionada.
2.20.3. La plataforma deberá mostrar en forma automática y continua, un resumen del estado del ambiente de virtualización, considerando el número de clúster, número de servidores físicos, número de servidores virtuales activos y el número de servidores virtuales suspendidos.
2.20.4. En ambientes de virtualización, la plataforma deberá mostrar el estado de consumo de recursos de los servidores físicos que conforman el entorno, presentando las siguientes métricas: uso de CPU, memoria, latencia de disco y utilización de la red.

2.21. Servicios de nube privada o pública
2.21.1. La plataforma deberá tener la capacidad de monitorear el consumo de recursos tecnológicos del ICE que estén hospedados en las plataformas Microsoft Azure, Amazon o su equivalente.
2.21.2. La plataforma deberá tener la capacidad para correlacionar los componentes descubiertos On-Premise y aquellos identificados como un servicio en una nube pública, de forma tal que sirvan de insumos en el análisis de problemas e identificación de causa raíz.
2.22. Tableros (dashboards)
2.22.1. Con el objetivo de obtener información resumida y detallada para el análisis y la toma de decisiones, la plataforma deberá permitir mostrar la información en gráficos predefinidos para las principales métricas y análisis. Igualmente deberá permitir la creación y personalización de paneles con la inclusión o eliminación de información o gráficos en cada panel.
2.22.2. La plataforma deberá facilitar el compartir los tableros de manera sencilla por medio de un enlace. Además, deberá permitir el copiado y eliminación de los tableros en el momento que el usuario lo requiera.
2.22.3. La plataforma deberá permitir la creación de más de un panel de componentes con visiones diferentes, permitiendo que cada uno de ellos sea compartido. En estos paneles deberá ser posible incluir información relacionada a negocio, aplicaciones, procesos e infraestructura.
2.22.4. Los dashboards deben ser personalizables por servicio, aplicación o unidad organizacional. Asimismo, la información mostrada debe ser en tiempo real, debe existir la posibilidad de proyectar información específica en un momento del tiempo, bajo un esquema tipo “notebook”.
2.23. Reportes
2.23.1. La plataforma deberá poder generar un reporte sobre la calidad del servicio, generando una calificación total del entorno de monitoreo, incluyendo notas independientes para las aplicaciones, servicios e infraestructura.
2.23.2. La plataforma deberá generar un reporte de disponibilidad de servicio, que incluya los principales elementos relacionados con los chequeos de disponibilidad de las aplicaciones. Este reporte deberá considerar: porcentaje de disponibilidad, tiempo de respuesta promedio, fechas de caídas, mejores y peores tiempos de respuesta, gráfico de tendencias para la disponibilidad y los tiempos de respuesta.
2.23.3. La plataforma deberá permitir que los reportes sean compartidos por medio de un enlace copiado y enviado por correo. También, deberá ser capaz de generar reportes en PDF o equivalente los cuales puedan ser modificados con el formato del ICE.
2.24. Análisis de problemas
2.24.1. La plataforma debe correlacionar automáticamente eventos provenientes de múltiples fuentes de datos (logs, métricas y trazas) e integrar de forma inteligente los incidentes de los componentes tecnológicos monitoreados en un único incidente, identificando la causa raíz y su impacto, con el fin de facilitar el análisis y minimizar las ‘tormentas de alarmas’ propias de los sistemas tradicionales de monitoreo.
2.24.2. Con el objetivo de analizar problemas pasados, la plataforma deberá mantener un histórico, de doce (12) meses, de los problemas ocurridos, para ser analizados en cualquier momento, mostrando para cada uno, los datos, eventos, métricas, y el comportamiento de los componentes tecnológicos que fueron monitoreados en ese momento del tiempo. La plataforma deberá contar con un mecanismo de grabación del comportamiento de los componentes tecnológicos, mostrando la evolución de problema a lo largo del tiempo, de manera tal que permita observar todos los eventos que se presentaron. Para los problemas identificados, la plataforma deberá contabilizar y mostrar el número de usuarios, llamadas a servicios, aplicaciones y componentes de infraestructura afectados, de manera tal que pueda establecerse de forma concreta, su impacto y determinar así la prioridad de atención de cada problema.
2.24.3. La plataforma debe contar con capacidades de detección de anomalías basada en inteligencia artificial o aprendizaje automático.
2.24.4. La plataforma debe contar con un motor de reglas para la definición de umbrales y condiciones de alerta, además del motor de alertas automático, donde tendrá preponderancia las reglas personalizadas definidas por los equipos técnicos de los sistemas monitoreados.
2.24.5. La plataforma debe contar con diferentes niveles de alerta, donde se tengan definidas prioridades, así como la capacidad de generar prioridades personalizadas y escalamiento automático.
2.25. Análisis de archivos de logs
2.25.1. La plataforma deberá realizar el análisis de los archivos de logs de los servicios, eventos del sistema operativo, de base de datos, de un componente, procesos, aplicaciones e infraestructura, o cualquier archivo que tenga esta finalidad. La plataforma deberá tener la capacidad de almacenar la ubicación de cada fuente de datos mencionada, de forma que solo se le deba configurar una única vez de su ubicación y que, en ejecuciones posteriores, busque automáticamente donde están estos archivos, es decir, no deberá ser necesario informar en reiteradas ocasiones la ubicación de ellos. Con esto se espera que sea posible incluir dentro de los análisis de causa raíz los eventos de estos logs.
2.25.2. En caso de que ocurra un problema (por ejemplo, caídas de procesos) y que esta sea registrada en un archivo de logs, la plataforma deberá emitir una alerta, además identificar el impacto del problema y la causa raíz de este.
2.25.3. La plataforma deberá permitir crear reglas específicas de análisis automático de archivos de logs, permitiendo la búsqueda de alarmas. Para la creación de estas reglas, el módulo deberá permitir identificar palabras específicas o combinaciones, además del número de ocurrencias por unidad de tiempo. La plataforma deberá permitir indicar en cuales archivos de logs esta regla será aplicada de manera selectiva, logrando extender aún más las capacidades de análisis y diagnóstico.
2.25.4. La plataforma de observabilidad deberá tener la capacidad incluida de detección y análisis automático de archivos de log, filtrar logs por palabras clave y rangos de tiempo, así como analizar múltiples archivos de logs a la vez.
2.25.5. La plataforma deberá poder crear eventos y disparar notificaciones a través de palabras claves registrados en los archivos de log.
2.25.6. El único agente instalado por servidor deberá contar con todas las capacidades descritas anteriormente, para evitar análisis manuales de logs o incrementar el número de herramientas de monitoreo y análisis.
2.25.7. Deberá contar con la posibilidad de procesar archivos de logs de dispositivos tipo appliance que no tengan la capacidad de instalar el agente de monitoreo; sin embargo, que puedan enviar logs a través de tecnologías como syslog.
2.26. Herramientas de diagnóstico
2.26.1. Con el objetivo de acelerar el proceso de diagnóstico de comportamientos anormales y mejora continua de las aplicaciones, la plataforma deberá permitir realizar un análisis del consumo histórico de CPU de los procesos monitoreados.
2.26.2. La plataforma deberá permitir la identificación de los procesos que más consumen recursos de CPU en todo el entorno de monitoreo. Para cada proceso, deberá ser posible identificar el nivel de contribución porcentual de cada clase y/o método (cuando el lenguaje de programación así lo permita).
2.26.3. La plataforma deberá permitir el análisis de utilización de CPU, de cada uno de los procesos de “garbage collector”, con el objetivo de determinar causas de falla y/o problemas de rendimiento de las aplicaciones.
2.27. Enriquecimiento de la CMDB.
2.27.1. La plataforma deberá tener la capacidad de enriquecer los configuration items (CI) y relaciones desde la topología descubierta en tiempo real por la solución de monitoreo.
2.27.2. La plataforma deberá tener la capacidad de unir entidades de la plataforma de monitoreo a la metadata de la CMDB para automatizar los flujos de incident management y remediación.

2.28. Valor al Negocio y Business Analytics
2.28.1. La plataforma deberá permitir configurar y definir transacciones o eventos de negocio directamente dentro de la misma herramienta, sin depender de módulos o productos adicionales. Esto permitirá dar seguimiento a procesos clave del negocio (como pedidos, pagos o registros) visualizando cómo fluyen de principio a fin, e identificando en qué punto pueden presentarse demoras, errores o interrupciones, de forma clara y comprensible incluso para usuarios no técnicos.
2.28.2. La plataforma deberá tener la capacidad para capturar el tiempo y contexto a nivel de código para cada transacción (cuando el lenguaje de programación así lo permita).
2.28.3. La plataforma deberá tener la capacidad para registrar cada petición a través de todas las capas sin espacios ni puntos ciegos (end to end).
2.28.4. La plataforma deberá tener la capacidad para obtener métricas de rendimiento por servicios, capas, interdependencias y tiempos entre capas automáticamente y en tiempo real.
2.28.5. La plataforma deberá tener la capacidad mediante la inteligencia artificial poder analizar en tiempo real todas las transacciones, detectar automáticamente anomalías y analizar a nivel de código para dar la causa raíz de problemas.
2.28.6. La plataforma deberá analizar las transacciones de negocio basado en detectar cuellos de botella en el rendimiento, llamadas a base de datos, complejidad de la arquitectura o llamadas asíncronas.
2.28.7. Compartir información al negocio a través de dashboards personalizados y reportes calendarizados.
2.28.8. Identificar cada usuario que ejecuta cada transacción de negocio (cuando la aplicación cuente con autentificación).
2.28.9. Cada transacción de negocio se deberá mostrar en contexto con microservicios, contenedores, infraestructura y métricas en la nube.
2.28.10. La plataforma deberá tener la capacidad de extraer propiedades, acciones o métricas desde las sesiones de los usuarios o desde las clases y métodos de las aplicaciones y transacciones para generar dashboards de negocio tales como embudos de conversión.
2.29. Seguridad
2.29.1. Como parte de la plataforma, la misma deberá contar integralmente con la funcionalidad de detección de vulnerabilidades en tiempo real en aplicaciones web en tecnologías java, .NET, PHP, entre otras (cuando la tecnología así lo permita).
2.29.2. La plataforma deberá incluir en el “gráfico de relaciones” de forma automática y continua de todos los componentes tecnológicos descubiertos, las vulnerabilidades aplicativas, esto según corresponda.
2.29.3. La plataforma deberá permitir la observabilidad mediante el único agente instalado en el equipo, y deberá tener la capacidad de detectar vulnerabilidades de terceros en tiempo real y mostrarlas como parte integral del mapa de servicios indicando los elementos afectados dentro de este mapa de servicios y dependencias.
2.30. Literatura técnica
2.30.1. El oferente deberá aportar, literatura técnica en inglés y/o español del software ofertado que permita determinar claramente las características de la plataforma.
2.30.2. El oferente deberá especificar claramente las condiciones, requisitos y restricciones para la instalación y puesta en marcha de cada una de las soluciones en la documentación técnica solicitada.
2.31. Disponibilidad de sitios web
2.31.1. La plataforma deberá proveer la flexibilidad de realizar monitoreo a determinados sitios web que el ICE utilice para el funcionamiento de sus aplicaciones. Además, deberá notificar cualquier funcionamiento incorrecto, caídas o degradaciones que comprometan la calidad de los servicios que el ICE ofrece.
2.31.2. La plataforma deberá contar con la infraestructura necesaria para poder realizar el monitoreo de disponibilidad de sitios web del ICE desde diferentes puntos distribuidos a nivel mundial.
2.31.3. La plataforma deberá ser capaz de desplegar agentes para el monitoreo de sitios web internos (sin salida a internet), para lo cual deben instalarse en la infraestructura del ICE.
2.32. Sesiones de usuario final
2.32.1. La plataforma deberá tener la capacidad de registrar individualmente el 100 % de las sesiones de los usuarios en las aplicaciones web y móviles. Cada usuario deberá ser identificado por su nombre o identificador alfanumérico o identificación numérica, según lo defina el ICE, de manera que sea posible observar y resolver los reclamos de un cliente en particular, en caso de ser necesario.
2.32.2. La plataforma deberá permitir la búsqueda de sesiones de usuario, utilizando criterios como: nombre de aplicación, navegador, ubicación geográfica, sistema operativo, cantidad de fallas, proveedor de servicios, resolución de pantalla, nombre de usuario, cantidad de acciones de usuario por sesión.
2.32.3. La plataforma deberá mostrar para cada usuario registrado: nombre del usuario, localización geográfica desde donde accede, promedio de acciones por sesión, promedio de duración de sesión, cantidad de sesiones registradas, cantidad de errores o fallas registradas.
2.32.4. La plataforma deberá mostrar para cada sesión de usuario: fecha y hora de la sesión, duración de la sesión, resolución de pantalla utilizada, sistema operativo, navegador, versión de navegador, dirección IP Pública (cuando esté disponible), ubicación geográfica (cuando esté disponible), cantidad y lista de acciones ejecutadas.
2.32.5. La plataforma deberá mostrar para cada acción de usuario (interacción con el navegador web que involucra una llamada al servidor web) que pertenezca a una sesión: tipo de acción, nombre de la acción, duración observada, errores registrados, índice de satisfacción de la acción (Apdex, www.apdex.org), tiempos de respuesta del servidor y de la red.
2.32.6. La plataforma deberá mostrar para cada acción de usuario que pertenezca a una sesión, un análisis detallado de cada elemento que fue solicitado al servidor y cargado en el navegador o móvil del usuario, considerando: duración total, tiempo de carga, tiempo de solicitud, tiempo de respuesta, tamaño del objeto.
2.33. Gestión de agentes de monitoreo y despliegue
2.33.1. La plataforma deberá permitir la actualización automática del software de monitoreo a las últimas versiones y funcionalidades durante la vigencia del contrato.
2.33.2. La plataforma deberá permitir el control de actualización de versiones automático o manual de los agentes instalados en los servidores por parte del usuario asignado por el ICE.
2.33.3. La plataforma deberá permitir en cualquier momento, la habilitación o deshabilitación del monitoreo específico de un servidor o proceso por parte del usuario asignado por el ICE.
2.33.4. La plataforma deberá realizar el monitoreo de los servidores solicitados accesibles a través de firewalls o dispositivos de seguridad instalados en el ICE.
2.33.5. La información capturada como parte del monitoreo deberá ser transmitida en forma encriptada para que entes no autorizados internos o externos al ICE estén impedidos a obtener información que a la larga pueda representar riesgos de seguridad.
2.33.6. La plataforma puede utilizar agentes instalados en los servidores y código inyectado en las aplicaciones web y móviles del ICE, para realizar la recolección de información del monitoreo de experiencia de usuario y de todos los componentes de tecnología, siempre y cuando no exista un impacto significativo en desempeño o funcionalidad en las aplicaciones. Esto por cuanto el ICE requiere métricas reales y totales para todas las sesiones de las aplicaciones de sus clientes y usuarios, en todo momento, desde cualquier lugar y dispositivo donde ocurran.
2.33.7. El monitoreo deberá iniciar en forma automática al finalizar la instalación de los agentes sin necesidad de realizar configuraciones manuales en los mismos.
2.33.8. El contratista deberá disponer de herramientas automatizadas de distribución masiva del software de monitoreo en los grupos de servidores que el ICE requiera para acelerar el proceso de despliegue de los agentes.
2.33.9. La plataforma deberá indicar los componentes de tecnología descubiertos en cada categoría (servidores, procesos, servicios y aplicaciones) indicando, aquellos en los cuales sea necesario realizar un reinicio para lograr su monitoreo completo. Esto con el objetivo de asegurar que todo componente tecnológico crítico se encuentra correctamente monitoreado.
2.33.10. La plataforma deberá administrar y mapear las instalaciones de los agentes en los servidores monitoreados, de manera que pueda conocerse su estado.
2.33.11. La plataforma deberá indicar de forma automática y continua, la cantidad de servidores, sesiones y chequeos de disponibilidad realizados en el entorno de monitoreo.
2.34. Integraciones
2.34.1. Integraciones nativas con herramientas de DevOps y CI/CD: Jenkins, GitHub Actions, GitLab CI/CD, Terraform, Ansible.
2.34.2. API RESTful o equivalente para integración personalizada con otros sistemas.

2.35. Requisitos de seguridad, integración y continuidad del servicio

2.35.1. El software deberá tener la capacidad de permitir informes de auditoría recientes o pruebas de calidad de software o ciberseguridad por terceros, que evalúen la calidad de software o servicio a contratar.
2.35.2. El contratista deberá contar con un plan de respuesta a incidentes en caso de que cualquier actualización o brecha de ciberseguridad a la licencia o suscripción cause afectación de continuidad del negocio.
2.35.3. El contratista deberá notificar a la Administración del Contrato ICE en caso de cualquier vulnerabilidad o incidente asociado a fallos de calidad o ciberseguridad en el software o servicio de suscripción, de forma inmediata al conocimiento del evento.
2.35.4. El contratista deberá garantizar la aplicación de actualizaciones o parches de calidad o ciberseguridad en el software a adquirir, definiendo previamente las responsabilidades del proveedor y del cliente ICE para la aplicación de las actualizaciones.
2.35.5. El software ofertado deberá brindar la posibilidad de integrarse al correlacionador de eventos (SIEM). El software o suscripciones adquiridos se deben configurar correctamente para que puedan enviar logs de analítica hacia el correlacionador de eventos de ciberseguridad (SIEM) del ICE, se deberá tomar en cuenta el formato de los logs, utilizar etiquetas como fuente, tipo de evento, fecha y hora locales.
2.35.6. Es importante que se configuren los parámetros correctos para que los datos se envíen de forma eficiente y que se pueda realizar una correlación adecuada, se recomienda el envío de logs en formatos establecidos por el ICE o en formato syslog, pero realizando previamente una normalización de los logs para que puedan correlacionarse en el SIEM del ICE.
2.35.7. El software ofertado debe implementar mecanismos de autenticación de tipo SSO (logueo único) y que se integren con el Active Directory institucional y Microsoft Entra ID.
2.35.8. El software ofertado debe tener un ciclo continuo de actualización para prevenir posibles fugas o ataques de exfiltrar los datos del mismo y proteger la información, amparado por la Ley 8968 LEY PROTECCIÓN DE LA PERSONA FRENTE AL TRATAMIENTO DE SUS DATOS PERSONALES, esto incluye la implementación de políticas de contraseñas seguras, cifrado de datos, monitoreo constante de la actividad de usuarios, según responsabilidad del fabricante.
2.35.9. El software ofertado debe implementarse inicialmente con la última versión estable existente en el mercado (el SaaS y sus agentes/colectores) y deben ser actualizadas con versiones previamente evaluadas y certificadas en evaluación de la calidad de software reconocidas, para garantizar que se estén utilizando las versiones más estables y seguras. La validación de las versiones estables más recientes también es importante para asegurar que se han corregido todas las brechas de ciberseguridad y vulnerabilidades conocidas que surgen de manera regular dentro toda la vigencia del contrato.
2.35.10. Si se detecta alguna vulnerabilidad o brecha de ciberseguridad en algún componente de software de la plataforma, el contratista deberá corregirla de manera inmediata y notificar a los usuarios afectados y al respectivo equipo administrador de la misma dentro del ICE.
2.35.11. Se deberá llevar un control de las actividades realizadas por los usuarios, para contar con un registro de auditoria técnico detallado y poder rastrear cambios no autorizados.
2.35.12. Las suscripciones (y sus componentes de software) no deben ser entregadas con parámetros por defecto, usuarios, contraseñas y los nuevos usuarios y roles se deben gestionar en conjunto con los administradores del ICE, según las necesidades, todo acceso deberá ser autenticado, autorizado y cifrado para prevenir incidentes de ciberseguridad. Todos los elementos de ciberseguridad deben mantener registro desde la implementación hasta la finalización del contrato.
2.35.13. El contratista deberá garantizar que las actualizaciones, nuevas versiones, parches o modificaciones de la plataforma mantengan las funcionalidades, capacidades e integraciones requeridas para el cumplimiento del objeto contractual. En caso de que una actualización implique cambios funcionales, operativos o de configuración que puedan afectar los procesos, integraciones, tableros, reportes, automatizaciones o cualquier otra funcionalidad utilizada por el ICE, el contratista deberá comunicarlo formalmente con antelación razonable, indicando el impacto esperado, los riesgos asociados, las acciones de mitigación y las alternativas disponibles. Ninguna actualización que pueda generar afectación significativa a la operación deberá implementarse sin la debida coordinación con el personal designado por el ICE.
2.35.14. El contratista deberá velar por el cumplimiento de todas las condiciones, funcionalidades y niveles de servicio establecidos en la presente contratación durante toda la vigencia contractual. Asimismo, deberá informar oportunamente al ICE sobre cualquier cambio en la plataforma, modelo de licenciamiento, arquitectura, componentes, funcionalidades, integraciones, políticas del fabricante o condiciones de soporte que puedan afectar el cumplimiento de los requerimientos contratados o desviar los objetivos previstos para el uso de la solución.
2.36. Integración con SAP

La solución de monitoreo y observabilidad deberá ser capaz de integrarse con entornos SAP Enterprise, proporcionando observabilidad integral sobre la infraestructura, aplicaciones y procesos de negocio SAP. A continuación, se detallan los requisitos técnicos y funcionales:
2.36.1. Integración con Soluciones SAP BTP y Aplicaciones Asociadas: La plataforma deberá integrarse con el ecosistema SAP Business Technology Platform (BTP) y sus aplicaciones asociadas, incluyendo:
• SAP SuccessFactors.
• SAP Ariba.
• SAP Cloud Platform Integration (CPI).
2.36.2. Cobertura Multidimensional de Casos de Uso SAP: La plataforma deberá ser capaz de generar y soportar casos de uso de monitoreo en múltiples dimensiones operativas de entornos SAP, incluyendo:
• Operaciones SAP (BASIS): monitoreo de instancias, procesos de trabajo, memoria, rendimiento de base de datos.
• Seguridad: auditoría de accesos, cambios de configuración, eventos de seguridad.
• Integración: monitoreo de flujos de integración, APIs, conectores y procesos de intercambio de datos,
• Procesos de negocio: trazabilidad de transacciones, rendimiento de módulos funcionales (FI, MM, SD, etc.).
2.36.3. Extracción Íntegra de Datos SAP. La plataforma deberá extraer datos de entornos SAP con total fidelidad y precisión, permitiendo:
• Captura completa de la telemetría disponible en SAP.
• Creación de casos de uso personalizados basados en datos específicos del cliente.
• Análisis granular sin pérdida de información.
2.36.4. Certificación y Compatibilidad SAP: La plataforma deberá ser compatible técnicamente con los siguientes entornos:
• SAP NetWeaver ABAP.
• SAP NetWeaver Java.
• SAP S/4 HANA (on-premises).
• SAP S/4 HANA RISE (SAP-managed cloud).
• SAP S/4 HANA Enterprise Cloud.
Para el cumplimiento de este punto el oferente deberá presentar ya sea la certificación oficial de SAP o carta de compatibilidad técnica emitida por el fabricante.
2.36.5. Arquitectura de Integración Agnóstica a la Infraestructura: La plataforma deberá permitir la integración con entornos SAP sin requerir la instalación de agentes en el sistema operativo del servidor SAP, garantizando compatibilidad con:
• Entornos on-premise.
• Entornos en nube pública.
• Entornos en nube privada.
• Arquitecturas híbridas.
2.36.6. Retención y Análisis Histórico de Datos SAP: La plataforma deberá conservar los datos sin procesar (raw data) de SAP de conformidad con la política de retención de datos definida por el ICE, permitiendo:
• Análisis forense histórico de eventos y transacciones.
• Establecimiento de líneas de base (baselines) basadas en telemetría histórica.
• Correlación temporal de eventos.
2.36.7. Visibilidad de Objetos de Integración SAP: La plataforma deberá ser capaz de capturar, monitorear y mostrar el contenido empresarial de objetos de integración SAP, incluyendo:
• iDocs (Intermediate Documents).
• Servicios web (Web Services).
• APIs de SAP.
• Otros mecanismos de intercambio de datos.
2.36.8. Extensibilidad Dinámica Post-Instalación: La plataforma deberá permitir la ampliación de funcionalidad de forma dinámica después de la instalación inicial, incluyendo:
• Extracción de tablas SAP personalizadas (tablas Z).
• Extracción de tablas SAP estándar adicionales.
• Creación de nuevos casos de uso sin redeployment de la solución.
• Configuración de nuevas métricas y eventos sin intervención del fabricante.
2.36.9. Tiempo de Implementación Acelerado: Los casos de uso de monitoreo listos para usar (out-of-the-box) deberán ser implementables en cuestión de horas, con un tiempo de instalación y configuración de 1 a 2 horas por entorno SAP.
2.36.10. Correlación de Datos SAP y No-SAP: La plataforma deberá ser capaz de correlacionar y analizar conjuntamente:
• Datos provenientes de entornos SAP.
• Datos provenientes de sistemas no-SAP (infraestructura, aplicaciones de terceros, etc.).
2.36.11. Normalización de Datos Pre-Ingesta: Los conjuntos de datos provenientes de SAP deberán ser normalizados antes de la ingesta en la solución de observabilidad, garantizando:
• Consistencia de formato.
• Eliminación de redundancias.
• Preparación para análisis y correlación.
2.36.12. Arquitectura de Integración Resiliente: La plataforma deberá utilizar una arquitectura de integración que cumpla con el modelo push con resiliencia temporal (desde SAP hacia la plataforma de observabilidad) con capacidad de retención temporal de datos en el punto de conexión en caso de interrupciones de conectividad, garantizando que:
• Los datos no se pierdan si la conexión con la plataforma se interrumpe temporalmente.
• Se reintente la transmisión automáticamente una vez restaurada la conectividad.
• Se mantenga la integridad de los datos.
2.36.13. Flexibilidad en Métodos de Extracción: La plataforma deberá permitir múltiples métodos de extracción de datos de SAP, incluyendo:
• Extracción mediante APIs disponibles en SAP.
• Extracción mediante métodos alternativos cuando las APIs no estén disponibles.
• Adaptabilidad a diferentes versiones y configuraciones de SAP.
2.36.14. Requisitos de Conectividad: La integración deberá requerir únicamente la apertura de puertos de red de salida desde el entorno SAP hacia la plataforma de observabilidad, sin requerir:
• Apertura de puertos de entrada hacia el servidor SAP.
• Instalación de agentes en el sistema operativo.
• Cambios significativos en la arquitectura de red existente.

3. REQUERIMIENTOS TÉCNICOS ESPECÍFICOS:
3.1. LÍNEA 1: SERVICIO DE SUSCRIPCIÓN EN LA NUBE DE PLATAFORMA DE SOFTWARE DE MONITOREO Y OBSERVABILIDAD DE LOS SERVICIOS DE TECNOLOGÍAS DE INFORMACIÓN
3.1.1. Arquitectura del Servicio
3.1.1.1. El servicio de suscripción ofertado deberá permitir al ICE integrar, bajo el modelo de software como servicio (SaaS), una plataforma única de monitoreo y observabilidad extremo a extremo del ecosistema digital del Instituto El ICE cuenta con servidores distribuidos en los centros de datos a lo largo del territorio costarricense, donde deberá desplegar la solución.
3.1.1.2. Este servicio de suscripción deberá aprovisionarse mediante un tenant de uso exclusivo para el ICE, cuyo uso debe garantizarse durante toda la ejecución contractual, es decir, debe utilizarse el mismo tenant tanto durante la ejecución del contrato original hasta la posible ejecución de las prórrogas.
3.1.1.3. El contratista podrá adquirir la plataforma directamente con el proveedor/fabricante de la solución. En esta modalidad, el contratista será responsable de gestionar la contratación y la facturación correspondiente, garantizando el aprovisionamiento del ambiente SaaS.
3.1.1.4. La demanda será según la cantidad de instancias necesarias para abarcar toda la infraestructura de tecnologías de información del ICE distribuida en los diferentes centros de datos y/o nube.
3.1.1.5. Capacidadd de escalado automático en función de la carga.
3.1.2. Gestión Multitenant / Multiusuario
3.1.2.1. Soporte para múltiples usuarios y roles con permisos diferenciados (acceso al ambiente general y al panel de administración).
3.1.2.2. Posibilidad de segmentar la observabilidad por departamentos o unidades.
3.1.2.3. Capacidad de aislar datos entre distintos entornos (producción, pruebas, desarrollo).
3.1.3. Requisitos Técnicos de la Suscripción
3.1.3.1. La suscripción deberá permitir la recopilación y análisis de métricas, logs y trazas de manera centralizada.
3.1.3.2. Compatibilidad con la infraestructura tecnológica de la institución, incluyendo servidores físicos, máquinas virtuales, contenedores y servicios en la nube (AWS, Azure, etc.).
3.1.3.3. La suscripción deberá brindar crear múltiples usuarios con distintos niveles de acceso y permisos.
3.1.3.4. La suscripción deberá tener escalabilidad para adaptarse a un aumento en la demanda de monitoreo sin afectar el rendimiento del sistema.
3.1.3.5. La suscripción deberá integrarse con herramientas de terceros y API para facilitar la automatización y análisis de datos.

3.2. LÍNEA 2: SERVICIO DE ADQUISICIÓN DE CRÉDITOS PARA CONSUMO DE CAPACIDADES DE SOFTWARE DE PLATAFORMA DE MONITOREO Y OBSERVABILIDAD EN LA NUBE
3.2.1. Modelo de Consumo
3.2.1.1. El contratista deberá ofrecer un modelo basado en créditos o unidades de consumo consumibles durante el plazo de 12 (doce) meses contratados.
3.2.1.2. Los créditos o unidades de consumo serán solicitados en el contrato original y sus prórrogas bajo un modelo según demanda, dado que puede variar la cantidad de créditos o unidades de consumo necesarios para cubrir la necesidad de monitoreo del negocio.
3.2.1.3. Los créditos deberán ser intercambiables por todas las capacidades de la plataforma de Observabilidad.
3.2.2. Flexibilidad y Elasticidad
3.2.2.1. Los créditos deberán utilizarse de manera flexible según las necesidades de consumo sin fijar cuotas por componente.
3.2.2.2. Capacidad de escalar dinámicamente el consumo sin necesidad de reconfigurar el contrato.
3.2.2.3. Posibilidad de utilizar créditos en distintos entornos o dominios (producción, pruebas, desarrollo).
3.2.3. Gestión del Consumo
3.2.3.1. Panel de control para seguimiento detallado del consumo de créditos en tiempo real.
3.2.3.2. Posibilidad de establecer alertas de consumo o límites presupuestarios.
3.2.3.3. Capacidad de generar reportes automáticos de uso mensual, por tipo de recurso, equipo o aplicación.
3.2.3.4. API para integración con herramientas de gestión financiera o ERP.
3.2.4. Validez y Vigencia
3.2.4.1. Los créditos adquiridos deben tener validez durante el plazo de 12 (doce) meses contratados.
3.2.5. Transparencia y Facturación
3.2.5.1. Facturación clara y desglosada por:
• Tipo de capacidad utilizada.
• Cantidad de créditos consumidos.
• Fechas y períodos de consumo.
• Acceso a histórico de consumo y reportes para auditoría financiera y técnica.
3.2.6. Suscripción Integral con Pool de Consumo Anual (Créditos/Unidades)
3.2.6.1. El contratista proporcionará un Pool de Consumo Anual expresado en créditos o unidades de consumo, los cuales serán plenamente fungibles e intercambiables entre todas las capacidades de la plataforma (infraestructura, APM, logs, trazas, métricas, RUM, sintéticos, seguridad, etc.), de conformidad con la Tabla de Equivalencias (Rate Card) presentada en la oferta.
3.2.7. Vigencia y Gestión del Pool
3.2.7.1. El Pool de Consumo se asignará anualmente y podrá incrementarse según las necesidades. Los créditos y unidades de consumo no utilizados al finalizar el período contractual se acumularán automáticamente para el año siguiente, siempre que el fabricante lo autorice. El contratista será responsable de ejecutar este proceso de "carryover", asegurando la correcta transferencia, validación y continuidad de los créditos entre los periodos e informar al personal de ICE una vez completado.
3.2.8. Apertura Tecnológica y Neutralidad
Para garantizar la participación de diversos fabricantes, el ICE aceptará diferentes nomenclaturas de "Créditos" o "Unidades", siempre que el oferente cumpla con:
3.2.8.1. Conversión a Escenarios. El oferente deberá ser capaz de brindar una tabla de equivalencias junto con su oferta, donde indique la unidad propia y su conversión/equivalencia en créditos o unidades de consumo. Esto permitirá al ICE comparar basándose en el costo total de la solución para una carga de trabajo real, independientemente de cómo cada fabricante nombre a su unidad de medida.

3.2.9. Participación de soluciones con modelos comerciales distintos al esquema de créditos o unidades de consumo
En caso de que el oferente utilice un modelo comercial distinto al esquema basado en créditos para el consumo de capacidades (por ejemplo: licenciamiento por producto, host, volumen de datos, usuario, métricas, memoria, capacidad computacional u otro similar), deberá presentar una Tabla de Equivalencias técnica y comercial, clara, verificable y auditable, que permita homologar su modelo de consumo al esquema de unidades de crédito requerido por el ICE.
Dicha tabla deberá detallar la metodología de conversión propuesta, indicando las equivalencias entre las unidades comerciales propias de la solución ofrecida y las unidades de crédito solicitadas por el ICE, con el fin de permitir:
• La evaluación económica comparativa entre ofertas.
• El control y seguimiento contractual del consumo.
• La proyección y planificación presupuestaria.
• La gestión de facturación bajo modalidad según demanda.
El oferente deberá presentar la siguiente información en su tabla de equivalencias:

Campo	Descripción y Requisitos
Unidad comercial del fabricante	Nombre exacto y código de la unidad según la nomenclatura del proveedor (ej: "host APM Pro", "GB de logs ingeridos", "usuario RUM activo", "métrica activa", "traza distribuida", etc.).
Descripción técnica y alcance	Descripción detallada de qué incluye y qué NO incluye esa unidad. Debe indicar explícitamente: componentes monitoreados, retención de datos incluida, límites de cardinalidad, excepciones, y cualquier condición que afecte el consumo. Ej: "Monitoreo de infraestructura + APM + logs del agente instalado en el servidor, con retención de 30 días, sin costo adicional por alta cardinalidad hasta 10.000 series activas".
Precio unitario	Costo por unidad en USD (según la oferta), indicando la periodicidad (por hora). Debe ser un precio fijo y sin variaciones.
Equivalencia en créditos o unidades de consumo	Número de créditos o unidades de consumo equivalentes a 1 unidad del proveedor. La conversión deberá ser clara y verificable (ej: "1 host APM Pro = 72 créditos o unidades de consumo").
Condiciones, límites y excepciones	Indicar: mínimos de consumo, máximos, reglas de redondeo, períodos de facturación, excepciones por alta cardinalidad, y cualquier otra condición que afecte el cálculo del consumo.

3.2.10. Compromiso de Estabilidad Contractual y Transparencia
El contratista deberá:
3.2.10.1. Permitir consumo por demanda según las necesidades operativas del ICE, sin requerir:
• Compra de "paquetes" o "bundles" predefinidos.
• Migraciones de plan o cambios de edición.
• Recontratación o renegociación de términos.
• Ni aprobación previa del contratista para habilitar funcionalidades.
3.2.11. Medición, Auditoría y Reportes de Consumo
3.2.11.1. Medición verificable y auditable. El consumo deberá ser medible por la plataforma, auditable y exportable mediante:
• Portal de administración del ICE (dashboard).
• API de reportes.
3.2.11.2. Los reportes deberán incluir desglose por:
• Capacidad o componente consumido.
• Periodo (día, mes).
• El consumo asociado a cada entidad, proyecto, etiqueta o centro de costo, cuando la plataforma así lo permita.
3.2.11.3. El ICE tendrá acceso permanente a reportes de consumo histórico y proyectado, desde el portal de la plataforma y/o API de reportes.
3.2.12. Alertas, Umbrales y Control Presupuestario
La plataforma deberá permitir al ICE:
• Configurar umbrales y alertas por consumo (por porcentaje del pool anual).
• Acceder a reportes de proyección de consumo (forecast).
3.2.13. Protección de Condiciones Comerciales y No Degradación
Durante la vigencia contractual:
• El contratista deberá notificar al ICE cualquier modificación o actualización relacionada con la Tabla de Equivalencias. Dichas modificaciones requerirán, en todos los casos, la aprobación previa y el consentimiento expreso y por escrito del ICE, lo cual será comunicado oportunamente al contratista. El contratista no podrá realizar modificaciones unilaterales a las equivalencias, factores de conversión, reglas de cómputo, valores mínimos, criterios de redondeo, ni introducir cargos adicionales por módulos o capacidades que hayan sido previamente incluidos dentro de la suscripción integral ofertada y aceptada al momento de la adjudicación.
• Si la plataforma adquirida evoluciona o se actualiza, el contratista debe garantizarle al ICE la continuidad de las capacidades funcionales contratadas, manteniendo el esquema de Pool de Consumo y Tabla de Equivalencias acordado.
• En caso de discontinuación de una funcionalidad en uso por el ICE, el contratista deberá ofrecer una alternativa equivalente, en caso de no existir, se debe valorar la forma de abastecer la necesidad en conjunto con el área técnica del ICE.
3.2.14. Elementos fuera del alcance
Quedan excluidas del alcance de la suscripción integral:
• Aprovisionamiento de infraestructura propia del ICE destinada para esta plataforma.
• Integraciones con sistemas de terceros que requieran licenciamiento externo: El contratista debe señalar dentro de su oferta el costo de los sistemas de terceros que no puedan ser cubiertos mediante el modelo de créditos o unidades de consumo.
3.2.15. Escalabilidad y Flexibilidad
3.2.15.1. Al ser un contrato bajo la modalidad según demanda los pedidos de créditos se realizarán en cualquier momento y por la cantidad de créditos requeridas según las necesidades de la institución.
3.2.15.2. No se impondrán restricciones en la cantidad de créditos que pueden ser adquiridos o utilizados simultáneamente.

3.3. LÍNEA 3: SERVICIO DE CONFIGURACIÓN DE PLATAFORMA PARA SOFTWARE DE MONITOREO Y OBSERVABILIDAD EN LA NUBE.
3.3.1. Modelo de Consumo: El contratista deberá ofrecer un modelo basado en horas profesionales para la configuración de la plataforma.
3.3.2. Alcance de la Configuración
3.3.2.1. El contratista deberá realizar la configuración completa de la plataforma, incluyendo:
• Parametrización de recopilación de métricas, logs y trazas.
• Planificación y relevamiento inicial
• Configuración de dashboards, paneles e informes según las necesidades del ICE.
• Configuración de alertas, reglas y umbrales
• Configuración de notificaciones personalizadas.
• Configuración de zonas de configuración de colectores.
• Configuración de monitoreo sobre sitios web.
• Configuración de extensiones para monitoreo específico de tecnologías como bases de datos, virtualizadores, etc.
• Configuración de reportes de disponibilidad (SLO).
• Configuración para la correcta ingesta y análisis de logs.
• Configuración para el correcto uso de AI Ops.
• Integración con herramientas de comunicación y gestión de incidentes.
• Asegurar el correcto funcionamiento del software en los entornos especificados.
3.3.3. El contratista deberá realizar la instalación, configuración y puesta en funcionamiento del software en los entornos definidos por el ICE (nube), garantizando su correcta integración con la infraestructura tecnológica existente.
3.3.4. El contratista deberá realizar el levantamiento de requerimientos con el equipo técnico del ICE, con el fin de identificar las necesidades de monitoreo y observabilidad institucionales. Con base en la información recopilada, deberá proponer la estrategia más adecuada para atender dichas necesidades, presentando un plan de trabajo dentro de un plazo de cinco (5) días hábiles posteriores a la solicitud realizada por el ICE. El ICE facilitará para este análisis del entorno actual la siguiente información:
• Arquitectura de sistemas
• Herramientas y flujos de trabajo existentes
• Nivel deseado de observabilidad
3.3.5. El contratista deberá elaborar de plan de trabajo y cronograma de ejecución.
3.3.6. El contratista deberá asegurar la escalabilidad y redundancia de la solución.
3.3.7. Automatización e Instrumentación
3.3.7.1. Instalación y configuración de agentes o SDKs necesarios.
3.3.7.2. Automatización de despliegue mediante scripts o herramientas como Ansible, Terraform o Helm (para Kubernetes).
3.3.7.3. Instrumentación de servicios para trazas distribuidas con OpenTelemetry u otro estándar.
3.3.8. Dashboards y Visualización
3.3.8.1. Creación de dashboards personalizados por área o tipo de sistema (infraestructura, aplicaciones, seguridad, etc.).
3.3.8.2. Visualizaciones en tiempo real y filtros por etiquetas, entornos o servicios.
3.3.8.3. Configuración de vistas por usuario o rol.
3.3.9. Alertas y Umbrales
3.3.9.1. Configuración de alertas con reglas definidas por el ICE.
3.3.9.2. Uso de condiciones basadas en múltiples fuentes (logs, métricas, trazas).
3.3.9.3. Escalamiento de alertas y canalización a sistemas externos.
3.3.9.4. Pruebas de funcionamiento de alertas al finalizar la configuración.
3.3.10. Pruebas y Validación
3.3.10.1. Realización de pruebas funcionales para validar:
• Correcta ingesta de datos
• Funcionamiento de dashboards y consultas
• Activación y entrega de alertas
3.3.10.2. Validación con usuarios clave del cliente.
3.3.10.3. Acompañamiento técnico, según la necesidad del personal del ICE durante el periodo del contrato, abarcando (más no limitado) temas como:
• Uso de la plataforma
• Interpretación y uso de datos
• Análisis de logs, eventos, trazas y métricas
• Análisis de RUM
• Mantenimiento básico/avanzado de la configuración
3.3.11. Soporte Posterior a la Configuración
3.3.11.1. Soporte técnico posterior por un período de 30 días hábiles para:
• Ajustes de configuración
• Corrección de errores de implementación
• Acompañamiento en la estabilización del servicio
3.3.12. Gobernanza
3.3.12.1. El contratista deberá contribuir con la definición de roles y gobernanza, para asegurar que cada usuario tenga únicamente habilitados los permisos que requiere, esto con el fin de evitar expandir la superficie de ataque en caso de vulnerabilidades.
3.3.12.2. El contratista deberá configurar la autenticación con el uso del Active Directory institucional, con el apoyo del equipo técnico del ICE.
3.4. LÍNEA 4: SERVICIO DE IMPLEMENTACIÓN DE AGENTES SOFTWARE DE PLATAFORMA DE SOFTWARE DE MONITOREO Y OBSERVABILIDAD EN LA NUBE
3.4.1. Modelo de Consumo
3.4.1.1. El contratista deberá ofrecer un modelo basado por unidad de crédito, donde una unidad es un agente de monitoreo implementado según la necesidad del ICE.
3.4.2. Alcance del Servicio
3.4.2.1. El contratista deberá desplegar e integrar los agentes necesarios en los servidores, plataformas, aplicaciones y servicios a monitorear, de acuerdo con las instrucciones técnicas del ICE.
3.4.2.2. Instalación, configuración y validación de agentes de monitoreo/observabilidad para las tecnologías listadas en el apartado 2, salvo las integraciones tipo agentless.
3.4.3. Requerimientos Previos de Infraestructura
3.4.3.1. Identificación de puertos, usuarios y permisos requeridos para la instalación de agentes.
3.4.3.2. Configuración de conectividad a los colectores/enrutadores del tráfico hacia la plataforma en la nube.
3.4.3.3. Verificación de compatibilidad de versiones del sistema operativo y del agente.
3.4.4. Parámetros de Configuración Inicial
3.4.4.1. Configuración mínima de cada agente deberá incluir:
• Tags o labels de identificación por entorno, unidad organizacional y ubicación.
• Nivel de log para depuración.
• Habilitación de los módulos requeridos (logs, métricas, trazas).
• Conexión segura con endpoint de la plataforma en la nube (token/API key).

3.4.5. Validación Técnica de Implementación
3.4.5.1. Verificación de conectividad del agente con la plataforma.
3.4.5.2. Confirmación de ingesta de datos (heartbeat del agente, primera métrica recibida).
3.4.5.3. Registro de instalación exitosa con código de estado.
3.4.5.4. Prueba básica de recolección de logs y métricas.
3.4.6. Documentación de Implementación
3.4.6.1. Informe técnico en un plazo de 10 días hábilies con:
• Lista de nodos donde se instaló el agente
• Fecha/hora de instalación
• Logs de instalación
• Estado final del agente (activo, en espera, con error)
3.4.6.2. Manual o instructivo para el mantenimiento o reinstalación, para ser ejecutado por parte del personal técnico del ICE.
3.4.7. Seguridad en la Instalación
3.4.7.1. Uso de credenciales temporales o cifradas para la instalación.
3.4.7.2. Acceso remoto controlado mediante VPN, túnel seguro o sesión supervisada, previa autorización por parte del personal ICE.
3.4.7.3. Eliminación de scripts o archivos temporales tras la instalación.
3.4.7.4. Cumplimiento con políticas de seguridad del ICE (registro, auditoría, gestión de permisos).
3.4.8. Tiempo de Ejecución y Escalabilidad
3.4.8.1. Tiempo por instalación de agente: 10 a 30 minutos por host.
3.4.8.2. Capacidad de ejecutar instalaciones masivas (50 nodos por día).
3.4.8.3. Posibilidad de realizar el servicio de forma remota o presencial según necesidad.
3.4.9. Soporte y Garantía Técnica
3.4.9.1. Soporte técnico por 15 días naturales posterior a la instalación para:
• Solución de errores de conexión
• Reinstalación en caso de fallo
• Validación del funcionamiento del agente
3.4.9.2. Se deberá realizar un entregable con el registro de incidentes o problemas durante el proceso y plan de resolución.
3.4.10. Servicio de Implementación de Agentes de la Plataforma
3.4.10.1. Para garantizar una cobertura total de monitoreo, el contratista deberá instalar y configurar los agentes de la plataforma en todos los servidores, dispositivos y aplicaciones indicadas por la Institución.
3.4.10.2. El ICE deberá poder desplegar el agente para monitorear servidores y servicios ubicados en su infraestructura, así como en sitios de terceros y nube pública.
3.4.11. Las condiciones para este servicio incluyen:
3.4.11.1. Despliegue Planificado: Elaboración de un plan de implementación detallado, con fases y pruebas escalonadas para minimizar interrupciones en los sistemas de producción. Deberá ser entregado al equipo técnico del ICE, a través de correo, previo a la instalación de los agentes.
3.4.11.2. Compatibilidad: Los agentes deben ser compatibles con el hardware y software de la Institución.
3.4.11.3. Optimización de Recursos: Los agentes deben estar configurados para consumir la menor cantidad posible de CPU, memoria y ancho de banda, sin afectar el rendimiento de los sistemas monitoreados.
3.4.11.4. Monitoreo de Infraestructura Crítica: Implementación en servidores, bases de datos, contenedores, redes, aplicaciones y otros elementos clave de TI.
3.4.11.5. Registro y Documentación: Entrega de un informe detallado con la lista de agentes instalados, su configuración y alcance.
3.4.11.6. Mantenimiento y Actualización: El contratista deberá entregar un plan de mantenimiento posterior a la instalación de los agentes, para asegurar que se mantengan actualizados y operativos.
3.4.11.7. Todos los entregables de los dos puntos anteriores deberán ser entregados al finalizar o concluir la instalación de los agentes. Deberá ser entregado cuando se concluya el proceso de instalación de los agentes, a través de correo, al equipo técnico del ICE.

3.5. LÍNEA 5: SERVICIO DE SOPORTE TÉCNICO SOBRE PLATAFORMA DE SOFTWARE DE MONITOREO Y OBSERVABILIDAD EN LA NUBE.
3.5.1. Modelo de Consumo
3.5.1.1. El contratista deberá ofrecer un modelo de soporte basado en la cantidad de créditos o unidades de consumo solicitadas en la línea 2, durante el plazo de doce (12) meses del contrato. Las órdenes de pedido correspondientes a esta línea estarán directamente vinculadas a las órdenes de la línea 2; en consecuencia, deberán emitirse y entregarse de manera simultánea y en igual cantidad.
3.5.2. Cobertura del Servicio
3.5.2.1. La demanda será de acuerdo con la cantidad de créditos solicitados en la línea dos (2).
3.5.2.2. Deberá brindarse el soporte al tenant aprovisionado al ICE, incluyendo todas las implementaciones y configuraciones realizadas.
3.5.2.3. Soporte tanto para entornos productivos como no productivos (pruebas, desarrollo).
3.5.3. Disponibilidad y Horarios
3.5.3.1. El contratista deberá ofrecer servicio de soporte 24/7 (24 horas, 7 días de la semana) asegurando la atención oportuna de incidentes, con tiempos de respuesta y resolución alineados a los niveles de servicio comprometidos.
3.5.4. Notificación de Incidentes
3.5.4.1. En el momento en que el ICE requiera solicitar soporte, notificará formalmente al contratista, por medio de los canales oficiales indicados por la empresa para la apertura de tiquetes.
El tiempo de notificación dependerá del nivel de criticidad del incidente:
• Para incidentes de alta criticidad, la notificación se realizará de forma inmediata, tan pronto como se detecte el incidente, independientemente del día y la hora.
• Para incidentes de media o baja criticidad, la notificación se realizará dentro del horario laboral establecido por el ICE.
3.5.5. Modalidades de Atención
• Soporte técnico deberá incluir:
• Atención remota vía portal, correo o videollamada
• Gestión de tickets vía sistema de soporte (propio o del cliente)
• Escalamiento con fabricante de la plataforma (si aplica)
3.5.6. Tiempo de primera respuesta según severidad:
El tiempo de respuesta debe ir asociado con los tiempos de atención indicados en el Cuadro No.2.
3.5.7. Tipos de solicitudes requeridas
3.5.7.1. Resolución de incidentes y errores de funcionamiento.
3.5.7.2. Asistencia para cambios menores en configuración que estén afectando el correcto monitoreo de los sistemas productivos.
3.5.7.3. Soporte para reinstalación o reconfiguración de agentes.
3.5.7.4. Revisión del estado de salud del sistema (opcional mensual o trimestral).
3.5.7.5. Aplicación de actualizaciones (major, minor y patches) cuando sea necesario.
3.5.8. Idioma y Comunicación
3.5.8.1. El soporte deberá brindarse en idioma español como idioma principal.
3.5.8.2. En caso de escalamiento con fabricante internacional, el contratista deberá fungir como intermediario y realizar las traducciones necesarias.
3.5.9. Seguridad y Acceso
3.5.9.1. El contratista deberá utilizar conexiones seguras (VPN, túneles cifrados, acceso controlado) para asistencia remota.
3.5.9.2. Cumplimiento con políticas de seguridad del ICE en cuanto a uso de credenciales, acceso supervisado y registros de auditoría.
3.5.9.3. Registro de todas las intervenciones realizadas en los sistemas.
3.5.10. Gestión del Conocimiento
3.5.10.1. Entrega de bitácoras mensuales de atención: tipo de incidentes, tiempos de respuesta, estado final.
3.5.10.2. Manuales o instructivos generados como parte de la solución a problemas comunes.
3.5.10.3. Recomendaciones de buenas prácticas conforme se identifiquen necesidades o mejoras.
3.5.10.4. El contratista deberá compartir procedimientos estandarizados para resolución de incidentes comunes (runbooks).
3.5.10.5. Como parte del servicio de soporte, el contratista deberá proporcionar acompañamiento técnico durante la atención y resolución de incidentes, mediante interacciones documentadas y actividades de trabajo colaborativo con el personal institucional. Estas acciones deberán permitir la transferencia de conocimiento asociada a los procedimientos ejecutados y a las soluciones implementadas, con el propósito de facilitar la continuidad operativa y la gestión autónoma de las actividades relacionadas con el servicio.
3.5.11. Actualizaciones y Mantenimiento
3.5.11.1. Asistencia en la aplicación de parches o actualizaciones del sistema, son responsabilidad del ICE.
3.5.11.2. Recomendaciones proactivas para mantener la estabilidad del sistema ante cambios del entorno.
3.5.11.3. El contratista deberá garantizar actualizaciones del software sin costos adicionales, con el fin de mantener la última versión estable instalada en los entornos monitoreados y observados, según lo requiera la plataforma.
3.5.11.4. Cualquier cambio que afecte la funcionalidad deberá ser notificado mediante correo electrónico al Responsable Técnico con una anticipación de 10 días hábiles y aprobado por la Institución.
3.5.12. Garantía y disponibilidad de la plataforma

3.5.12.1. El contratista deberá garantizar una disponibilidad del servicio estable, sin degradaciones, con una cobertura 24x7x365 y un nivel de disponibilidad mensual del 99,95 %. La inactividad equivale a un tiempo acumulado de 3 horas y 40 minutos por mes. Se excluyen de este compromiso los eventos provocados por factores externos fuera del control y administración del contratista, tales como fallas globales de conectividad a Internet o interrupciones en la infraestructura de nube sobre la cual opera la plataforma.
3.5.12.2. El contratista deberá brindar respuestas a inquietudes, consultas y soporte técnico en el uso de las capacidades de la plataforma; que el personal técnico del ICE pueda requerir para garantizar una administración apropiada.
3.5.12.3. La plataforma deberá contar con un entorno de aprendizaje accesible (tipo eLearning), que permita a los usuarios explorar e implementar tanto las funcionalidades ya establecidas de la plataforma como las nuevas características que se vayan incorporando, facilitando así su comprensión y aplicación práctica y al cual se tendrá acceso desde la implementación del tenant.
3.5.12.4. El contratista deberá informar al personal del ICE sobre las características de los productos vigentes y las nuevas características que se van liberando en la plataforma, así como indicar si hay “breaking changes” al momento de actualizar los agentes que puedan afectar el funcionamiento del monitoreo sobre los sistemas del ICE. Para ello puede brindar documentación del fabricante o ligas al sitio web del fabricante.

3.6. CONDICIONES DE ATENCIÓN Y RECUPERACIÓN DE INCIDENTES (SLA)
3.6.1. El contratista será responsable de garantizar la atención y recuperación de incidentes relacionados con el funcionamiento del software de observabilidad y monitoreo contratado con un SLA esperado: 99,95 % de disponibilidad. Para efectos de evaluación del servicio y su correcto direccionamiento, se establecen los siguientes niveles de prioridad, así como los tiempos permitidos para su atención y recuperación.
Cuadro N°2. Tabla de tiempos de atención y recuperación de incidentes.

Prioridad	Tiempo de Atención	Tiempo de Recuperación
Crítica	1 hora	4 horas
Alta	4 horas	8 horas
Media	8 horas	16 horas
Baja	24 horas	48 horas

3.6.2. Definiciones de Niveles de Prioridad y Tiempos de Respuesta
3.6.3. Prioridad Crítica: Incidentes con uno o más de los siguientes efectos:
3.6.3.1. Inoperatividad total del software que impide el monitoreo de sistemas y servicios críticos.
3.6.3.2. Corrupción del software que afecta funciones principales como la recolección, visualización o análisis de métricas, logs y trazas.
3.6.3.3. Pérdida de datos críticos relacionados con eventos, alertas o configuraciones del sistema.
3.6.4. Prioridad Alta: Incidentes con impacto significativo, pero no total:
3.6.4.1. Disminución del rendimiento o funcionamiento limitado de componentes que afecten la entrega de métricas o alertas en tiempo real.
3.6.4.2. Fallos recuperables mediante intervención manual, con baja recurrencia (es decir, 1 o 2 por semana).
3.6.4.3. Eventos repetitivos (más de cinco veces en una semana) que requieren intervención para restaurar la funcionalidad, sin causar interrupciones completas.
3.6.5. Prioridad Media:
3.6.5.1. Incidentes que afectan funcionalidades secundarias del sistema, sin comprometer la operación central.
3.6.5.2. Errores intermitentes en dashboards, notificaciones o integraciones con herramientas externas.
3.6.6. Prioridad Baja
3.6.6.1. Solicitudes de soporte relacionadas con ajustes menores, reportes visuales, configuración de usuarios o consultas generales.
3.6.7. Definiciones de Atención y Recuperación:
3.6.7.1. Medio de Atención: El contratista deberá informar los canales de atención que se establezcan para el ICE o este puede acordarse entre las partes. Esto debe definirse en los 10 días hábiles contados a partir del día hábil siguiente a la notificación del contrato.
3.6.7.2. Tiempo de Atención: Es el tiempo trascurrido desde el momento que inicia el primer contacto documentado con el personal del contratista (por medio del mecanismo que se acuerde entre las partes o el que defina en su defecto) para generar el reporte de incidente del ICE o quien recibe el servicio, hasta el momento en que el mismo, es informado mediante los canales oficiales de que está siendo atendido.
3.6.7.3. Tiempo de Recuperación: Es el tiempo transcurrido desde la conclusión del tiempo de atención hasta el momento en que se reporta la recuperación de la infraestructura o plataforma afectada. El equipo técnico del ICE confirmará que los mismos están funcionando normalmente.
3.6.8. Aspectos Generales
3.6.8.1. Incidentes originados por causas ajenas al software o fuera del alcance del contratista (como desastres naturales, fallos en servicios de terceros o infraestructura no administrada por el contratista) no estarán sujetos a estos SLA, pero deben ser reportados.
3.6.8.2. La clasificación de la prioridad será definida por el ICE, con base en los criterios establecidos.
3.6.8.3. El contratista podrá solicitar la reclasificación del incidente, debiendo justificar técnicamente su solicitud por los medios establecidos.
3.6.8.4. Todo incidente deberá ser documentado por el contratista, siguiendo los procedimientos definidos por la División Tecnologías de Información del ICE, procedimientos que serán informados oportunamente al contratista.
3.6.8.5. El cierre de cada incidente deberá incluir evidencia técnica de la recuperación, acciones realizadas y lecciones aprendidas, cuando aplique. El contratista deberá entregar un documento escrito con estas observaciones, a través de correo al equipo técnico del ICE; en caso de ser necesario, coordinará una sesión técnica para explicar lo realizado en la plataforma.
3.6.8.6. El contratista deberá realizar el proceso de reclamo sobre el incidente hacia su proveedor o fabricante de la solución (cuando aplique), según el procedimiento establecido por este y entregar el resultado de dicho proceso al personal del ICE.

1. Condiciones generales

Las Condiciones Generales que regirán para los procedimientos de contratación administrativa, tramitadas por el Instituto Costarricense de Electricidad, que en lo sucesivo se denominará ICE, Institución Autónoma de la de la República de Costa Rica, domiciliada en San José y con cédula jurídica Nº 4-000-042139-02, son las CONDICIONES GENERALES DEL CARTEL TIPO DE CONDICIONES PARA PROCESOS DE CONTRATACION ADMINISTRATIVA, publicadas en el Alcance N° 161 a La Gaceta N° 174 del 19 de setiembre del 2024. Se aplicará de forma supletoria la Ley General de Contratación Pública N° 9986 y su reglamento, tal y como dispone el artículo 20 de la Ley N° 8660.

Únicamente aplica lo referente al Capítulo I de Condiciones Generales.

Estas condiciones pueden ser accedidas por medio de la siguiente dirección electrónica: https://apps.grupoice.com/PEL/

Para la atención de las erogaciones de pago que se originen de este contrato que corresponde a presupuestos de años futuros, la dependencia incluirá en las cifras de formulación presupuestaria del año correspondiente el debido contenido presupuestario, el cual queda sujeto a la aprobación del presupuesto por parte de la Contraloría General de la República. En caso necesario, la dependencia se compromete a dotar del debido contenido presupuestario mediante el procedimiento interno de modificación presupuestaria.

2. Estructura de precio y presupuesto detallado:

Disposiciones para presentación de la oferta:

1.1. El oferente debe presentar la estructura de precio en conjunto con la oferta, estableciendo los siguientes rubros obligatorios: costos directos de mano de obra, costos directos de insumos, costos indirectos de mano de obra, costos indirectos de insumos, utilidad; las ofertas deben considerarlos todos, indicando para cada componente el valor correspondiente, de reportarse algún componente en cero el oferente debe justificarlo desde la oferta y la dependencia analizará el fondo y determinará el cumplimiento o no de la oferta. Los rubros deberán presentarse en valores absolutos y porcentuales. Se anexa el formato a utilizar. Dicha estructura será utilizada para el análisis de las ofertas y posteriormente, en caso de requerirse un reajuste/revisión de precios.

1.2. Forma de presentar la estructura de precios en la oferta:

a) Para el caso de contratación de servicios en modalidad según demanda la estructura de precios se solicitará por línea.

b) No obstante, tanto para bienes como para servicios el oferente podrá realizar las agrupaciones de líneas en la estructura de precios en los casos en que los costos sean proporcionalmente iguales para todas las líneas.

1.3. Forma de presentar el Presupuesto detallado:

a) En los procedimientos de servicios el oferente deberá presentar en conjunto con la oferta un presupuesto detallado y completo con todos los elementos de costo que lo componen. Se anexa el formato a utilizar.

b) El ICE se reserva la posibilidad de solicitar información adicional atinente a la composición de los precios contemplados en la oferta, cuando ello resulte necesario.

3. Requerimientos de Norma de Higiene y Seguridad Ocupacional para el oferente y contratista:

Se debe cumplir con lo estipulado en el apartado 7 del documento anexo denominado: “NORMA DE SEGURIDAD E HIGIENE OCUPACIONAL ICE”. numeral 7.1.3 y 7.1.4, según corresponda.

4. Criterios sociales:

1. El oferente debe presentar declaración jurada de cumplimiento con la promoción de la equidad de género.

2. El oferente deberá presentar declaración jurada en la que se indique que se cuenta con la Política de Espacio Libre de Toda Forma de Discriminación. En caso de contar con personal contratado con discapacidad indicarlo en dicha declaración.

5. Audiencia para Descuentos

1. De conformidad con el artículo 66 el Reglamento al Título II de la Ley N°.8660, la Administración podrá otorgar audiencias posteriores al acto de apertura a fin de que aquellas ofertas elegibles, tengan oportunidad de otorgar un descuento a su propuesta. Este descuento será considerado en la calificación de las ofertas. En cada cartel se dispondrá las reglas para la aplicación de descuentos.

2. La Proveeduría citará a los proponentes que cumplan técnica y legalmente, concediéndole el plazo establecido en la tabla de plazos vigente comunicada por la Dirección Proveeduría, fijándose la fecha y hora para presentar el descuento por medio del Sistema Digital Unificado o de manera física según corresponda al tipo de procedimiento y conforme disponga el cartel, sin que se afecten los demás términos de la propuesta efectuada. El descuento no podrá ser mayor a la utilidad establecida en el precio original.

3. Junto con la mejora de precios se deberá de presentar la nueva estructura de precio y la justificación de la disminución del precio.

4. El descuento debe estar exento de condicionamientos para que sea sujeto de aceptación.

5. No se aceptarán propuestas de descuento que no hubiesen sido presentadas en la audiencia fijada por la Proveeduría del ICE al efecto.

6. El oferente que ofrezca descuentos o mejoras en los precios, deberá incorporar la estructura del precio descontado, considerando todos los elementos que los componen, además de la estructura del precio sin descuento, asimismo en caso de presentar una mejora del precio, deberá justificar la disminución del precio.

7. La mejora aplica sobre el subtotal del precio, sin considerar impuestos de ninguna clase.

8. Se recomendará la adjudicación de la oferta que cotice el menor precio comparativo, después de aplicada la mejora de precios.

6. Cláusula Desempate:

En caso de que se presente un empate en la propuesta económica de los posibles oferentes, se convocará un sorteo público, el cual se podrá realizar en forma presencial. La fecha y hora será comunicada oportunamente. Para definir el desempate se utilizará una moneda. De lo anterior, se levantará un acta que será suscrita por los asistentes al evento.

7. Forma de entrega:

Parcial. Líneas 1-2-3-4-5.

8. Forma de Pago:

Línea 1-2-3-4-5: Se realizará un único pago por cada pedido, contra la presentación de la factura correspondiente, una vez que los servicios hayan sido recibidos a satisfacción por el ICE.

Todas las facturas deben emitirse por el concepto indicado en el pedido emitido, así como también señalar el número de procedimiento y número de pedido de acuerdo con lo publicado en la plataforma SICOP. El contratista deberá enviar la factura de forma electrónica al correo facturasice@ice.go.cr y deberá coordinar previamente con el administrador de contrato los requisitos para presentarlas. Las facturas se deben presentar por medio del sistema SICOP.

9. Otras cláusulas:

1. Cláusula / Convenio de confidencialidad: Se debe firmar un acuerdo de confidencialidad de la información (Non-Disclosure Agreement, NDA) entre las partes. Este acuerdo establecerá los lineamientos y obligaciones que se deberán seguir para asegurar un uso adecuado de la información que para efectos del objeto contractual se requiera intercambiar entre las partes. En un plazo de 20 días hábiles, contados a partir de la notificación del contrato en SICOP. El Administrador del Contrato del ICE velará por el cumplimiento de este punto.

2. Cláusula Acuerdo de Servicio (SLA): Se deberá firmar un acuerdo de nivel de Servicios (SLA) entre las partes. Este acuerdo indicará las condiciones requeridas para el aseguramiento de las prestaciones del servicio, las cuales se encuentran detalladas en documento anexo a este cartel. Dicho acuerdo deberá firmarse en un plazo no mayor a 20 días hábiles, posteriores a la notificación del contrato respectivo y será el Administrador del Contrato el responsable de velar por el cumplimiento de este punto y dejar constancia en el expediente de la contratación.

10. Obligaciones del ICE:

1. El ICE facilitará los recursos humanos necesarios para suministrar la información requerida y designará a las personas autorizadas como contactos para intermediar en la ejecución de los servicios, así como al personal que deba participar en las sesiones técnicas y en todos los procesos, ya sea de instalación, configuración, pruebas, atención de incidentes o cualquier otra actividad que se dé durante la ejecución contractual.
2. El ICE tramitará y supervisará, en caso de ser necesario, el ingreso a sus instalaciones y los accesos remotos, así como los permisos a los recursos pertinentes en los sistemas que se requieran, para el personal asignado a la ejecución del servicio por parte del contratista.
3. El ICE nombrará un responsable técnico, que velará por el cumplimiento y buena marcha de los trabajos relacionados con la ejecución del servicio. De igual manera será el responsable de brindarle al contratista toda la información necesaria.

11. Obligaciones del contratista:

El contratista deberá cumplir, de forma estricta, con las siguientes obligaciones durante la ejecución del contrato:
1. Proporcionar los datos requeridos y solicitados por parte del responsable técnico de los empleados del contratista ya sea para ingreso a los sistemas o para ingreso a las instalaciones (de ser requerido esto último).
2. Estar debidamente identificados si se encuentran dentro de las instalaciones ICE
3. Deberá entregar un plan de trabajo para ser evaluado por la administración del ICE 5 días hábiles posteriores a la notificación del contrato respectivo y, en conjunto, definirán los responsables de participar en las reuniones de revisión de avance del contrato.
4. Proveer los accesos, licencias, claves, usuarios y documentación necesarios para el correcto funcionamiento y administración de la plataforma contratada.
5. Realizar sesiones técnicas con el personal técnico designado por el ICE, en las cuales debe entregar documentación, buenas prácticas, manuales de operación y procedimientos técnicos necesarios para la administración y continuidad del servicio.
6. Asistir a las reuniones de coordinación, control de avance y seguimiento que convoque la Administración del Contrato o el Responsable Técnico designado por el ICE.
7. Presentar informes periódicos de forma mensual sobre la presentación o avance de los servicios contratados, donde se detalle el cumplimiento de hitos, el consumo de recursos, la atención de incidentes, y cualquier otra información requerida por el ICE como evidencia del cumplimiento contractual.
8. Garantizar el correcto funcionamiento del software y de las configuraciones entregadas durante toda la vigencia del servicio contratado para cada pedido, atendiendo sin costo los errores atribuibles a la implementación o al producto entregado.
9. El contratista deberá designar un encargado del contrato, quien actuará como líder técnico y fungirá como único canal oficial de comunicación entre el ICE y el contratista para todos los asuntos relacionados con la ejecución contractual.
10. En caso de que durante la ejecución contractual se requiera realizar cambio en el personal que brinda el servicio, el contratista deberá notificar al ICE con 5 días de anticipación presentando los atestados del nuevo recurso para su aprobación. El nuevo recurso deberá cumplir con todos los requisitos establecidos en este cartel.

12. Garantía de cumplimiento:

El contratista se compromete a mantener vigente la garantía de cumplimiento durante la ejecución del presente contrato, misma que se devolverá de acuerdo con lo establecido en el cartel.

En vista de que es un procedimiento bajo la modalidad según demanda y su adjudicación es por requerimiento completo, el monto de la garantía de cumplimiento corresponde al valor nominal obtenido de la multiplicación del monto total recomendado de consumo por el 5 %.