Contract
p
ELABORADO POR |
REVISADO POR |
APROBADO POR |
|
|
|
|
Yacimientos Petrolíferos Fiscales Bolivianos |
|
CRONOGRAMA DE PLAZOS
|
ACTIVIDAD |
FECHA y HORA |
DIRECCIÓN
|
|
|
|
|
|
|
1 |
Invitación a Empresas. (*) |
Fecha: 21/04/2015 |
Xxxxx Xxxxx Xx 000 Xxxxxxxx XXXX Xxxx 0x Gerencia Nacional de Contrataciones La Paz –Bolivia |
|
|
|
|
|
|
2 |
Consultas Escritas. (*) |
No Corresponde |
|
|
|
|
|
|
|
3 |
Reunión de Aclaración. (*) |
No Corresponde |
|
|
|
|
|
|
|
4 |
Presentación de Ofertas. (*) |
Fecha: 27/04/2015 |
Horas: 15:00 |
Xxxxx Xxxxx Xx 000 Xxxxxxxx XXXX Xxxx 0x Gerencia Nacional de Contrataciones La Paz –Bolivia |
|
|
|
|
|
5 |
Apertura de Ofertas. (*) |
Fecha: 27/04/2015 |
Horas: 15:30 |
Xxxxx Xxxxx Xx 000 Xxxxxxxx XXXX Xxxx 0x Gerencia Nacional de Contrataciones La Paz –Bolivia |
|
|
|
|
Fechas Fijas (*)
|
Yacimientos Petrolíferos Fiscales Bolivianos |
|
PRECIO REFERENCIAL
El precio referencial del presente proceso de contratación es de Bolivianos:
Nº |
DESCRIPCION DEL BIEN |
PRECIO REFERENCIAL |
||
CANTIDAD |
PRECIO UNITARIO Bs. |
PRECIO TOTAL Bs. |
||
1. |
ADQUISICION DE IPM/APM |
1 |
2.272.440,00 |
2.272.440,00 |
TOTAL BOLIVIANOS |
2.272.440,00 |
PARTE I
INFORMACIÓN GENERAL A LOS PROPONENTES
SECCIÓN I
GENERALIDADES
NORMATIVA APLICABLE AL PROCESO DE CONTRATACIÓN
El proceso de contratación para la adquisición de bienes, obras, servicios generales y servicios de consultoría se rige por el Reglamento Específico del Sistema de Administración de Bienes y Servicios – RE-SABS-EPNE- YPFB.
PROPONENTES ELEGIBLES
En la presente convocatoria podrán participar empresas legalmente constituidas en el Estado Plurinacional de Bolivia.
IMPEDIDOS PARA PARTICIPAR EN LOS PROCESOS DE CONTRATACIÓN
Están impedidos de participar, directa o indirectamente, en los Procesos de Contratación las personas naturales y jurídicas comprendidas en los siguientes incisos:
Que tengan deudas pendientes con el Estado, establecidas mediante pliegos de cargo ejecutoriados y no pagados.
Que tengan sentencia ejecutoriada, con impedimento para ejercer el comercio.
Que se encuentren cumpliendo sanción penal establecida mediante sentencia ejecutoriada por delitos comprendidos en la Ley N º 1743, de 15 de enero de 1997, que aprueba y ratifica la convención Interamericana contra la corrupción o sus equivalentes previstos en el Código Penal y Ley Anticorrupción Xxxxxxx Xxxxxxx Santa Xxxx.
Que se encuentren asociados con consultores que hayan asesorado o prestado servicios para la elaboración del contenido de Términos de Referencia o Especificaciones Técnicas, con excepción de las EPNES.
Que hubiesen declarado su disolución o quiebra.
Cuyos representantes legales, accionistas o socios controladores tengan vinculación matrimonial o de parentesco con la MAE o los designados por este en los procesos de contratación, hasta el tercer grado de consanguinidad y segundo de afinidad, conforme con lo establecido por el Código de Familia.
Los ex servidores públicos que ejercieron funciones en YPFB, hasta un (1) año antes del inicio de la contratación, así como las empresas controladas por éstos.
Los servidores públicos que ejercen funciones en YPFB, así como las empresas controladas por éstos.
Los proveedores adjudicados que hayan desistido de suscribir el contrato, órdenes de compra y/o servicio, no podrán participar hasta un (1) año después de la fecha de desistimiento; salvo causas de fuerza mayor, caso fortuito debidamente justificadas, o aceptadas por la entidad convocante, de acuerdo a la información registrada en el SICOES.
Los proveedores con los que se hubiese resuelto el contrato por causales atribuibles a estos, no podrán participar durante tres (3) años después de la fecha de la resolución. Asimismo aquellos proveedores que hubieran incumplido la orden de compra y/o servicio no podrán participar durante un (1) año después de la fecha de incumplimiento, de acuerdo a la información registrada en el SICOES y/o página de YPFB
PREPARACIÓN DE OFERTAS
Las ofertas deben ser elaboradas conforme a los requisitos y condiciones establecidos en el presente DCD, utilizando obligatoriamente los formularios establecidos en el DCD.
MONEDA DEL PROCESO DE CONTRATACION
Todo el proceso de contratación debe expresarse en Bolivianos.
COSTOS DE PARTICIPACIÓN EN EL PROCESO DE CONTRATACIÓN
Los costos de la elaboración y presentación de ofertas y de cualquier otro costo que demande la participación de un proponente en el proceso de contratación, cualquiera fuese su resultado, son total y exclusivamente propios de cada proponente, bajo su total responsabilidad.
IDIOMA
Todos los documentos de la oferta y los Formularios del presente DCD, deberán presentarse en idioma Español.
CANCELACION DEL PROCESO DE CONTRATACION
El RPC podrá cancelar, el proceso de contratación, de acuerdo a lo establecido en Reglamento Específico del Sistema de Administración de Bienes y Servicios – RE-SABS-EPNE- YPFB
DEVOLUCION DE DOCUMENTOS PRESENTADOS EN EL PROCESO DE CONTRATACION
Independientemente del resultado del proceso de contratación, YPFB procederá únicamente a la devolución de:
Muestras en el caso de haber sido solicitadas.
El resto de la documentación presentada en la ofertada quedara en custodia de YPFB para fines de control gubernamental.
SECCIÓN II
GARANTIAS
TIPOS DE GARANTIA
Las garantías cuando sean requeridas, deberán estar emitidas a la orden de YACIMIENTOS PETROLIFEROS FISCALES BOLIVIANOS o YPFB.
Asimismo se establecen los siguientes tipos de garantía:
Boleta de Garantía: Emitida por cualquier entidad de intermediación financiera bancaria o no bancaria, regulada y autorizada por la instancia competente y que cumpla con las condiciones de renovable, irrevocable y de ejecución inmediata.
Garantía a Primer Requerimiento: Emitida por cualquier entidad de intermediación financiera bancaria o no bancaria, regulada y autorizada por la instancia competente y que cumpla con las condiciones de renovable, irrevocable y de ejecución inmediata.
Póliza de Seguro de Caución a Primer Requerimiento: Emitida por cualquier compañía aseguradora, regulada y autorizada por la instancia competente y que cumpla con las condiciones de renovable e irrevocable.
GARANTÍA DE CUMPLIMIENTO DE CONTRATO
Con el objeto de garantizar la vigencia, conclusión y entrega definitiva del objeto del contrato, se aplicarán los siguientes parámetros:
Hasta Bs. 200.000.- (Doscientos Mil 00/100 Bolivianos) el proponente definirá el tipo de garantía a presentar.
De Bs. 200.001.- (Doscientos Mil Uno 00/100 Bolivianos) hasta Bs. 1.000.000.- (Un millón 00/100 bolivianos) YPFB definirá el tipo de garantía.
Superiores a Bs. 1.000.000.- (Un millón 00/100 bolivianos) las empresas deberán presentar Boleta de Garantía Bancaria.
Cuando el proceso de contratación se formalice a través de Orden de Compra no se requerirá la presentación de la garantía de cumplimiento de contrato.
GARANTÍA DE CORRECTA INVERSION DE ANTICIPO
NO CORRESPONDE
SECCIÓN III
ACTIVIDADES PREVIAS A LA PRESENTACION DE OFERTAS
ACTIVIDADES ADMINISTRATIVAS PREVIAS A LA PRESENTACIÓN DE OFERTAS
Se contemplan las siguientes actividades previas a la presentación de ofertas:
13.1 Inspección Previa
NO CORRESPONDE
13.2 Consultas Escritas sobre el DCD
NO CORRESPONDE
13.3 Reunión de Aclaración
NO CORRESPONDE
AJUSTE AL DCD O AMPLIACIÓN DE PLAZO PARA LA PRESENTACIÓN DE OFERTAS.
Se podrá ajustar el DCD o ampliar el plazo de presentación de ofertas, por las siguientes causas debidamente justificadas:
Producto de la Reunión de Aclaración.
Hechos de fuerza mayor o caso fortuito.
A iniciativa de YPFB.
SECCIÓN IV
DOCUMENTOS PARA LA PRESENTACION DE LA OFERTA
DOCUMENTOS DE LA OFERTA
Todos los Formularios de la oferta, solicitados en el presente DCD, se constituyen en Declaraciones Juradas.
Los documentos que deben presentar los proponentes, según sea su constitución legal y su forma de participación, son:
Formulario A-1 Carta de Presentación de Ofertas.
Formulario (s) Presentación Oferta Económica.
Formulario (s) Presentación de la Oferta Técnica
OFERTA PARA ADJUDICACIONES POR ITEMS O LOTES
Cuando un proponente presente su oferta para más de un ítem o lote deberá presentar una sola vez la documentación legal y administrativa, y una oferta técnica y económica para cada ítem o lote.
SECCIÓN V
PRESENTACIÓN Y APERTURA DE OFERTAS
PRESENTACIÓN DE OFERTAS, PLAZO, CAUSALES DE RECHAZO
Forma de presentación: La oferta deberá ser presentada en sobre cerrado dirigido a XXXX citando el objeto de la contratación y presentada en un ejemplar original.
Plazo y lugar de presentación: Las ofertas deberán ser presentadas dentro del plazo (fecha y hora) fijado y en el domicilio establecido en el presente DCD.
Las ofertas podrán ser entregadas en persona o por correo certificado (Courrier). En todos los casos el proponente es el responsable de que su oferta sea presentada dentro el plazo y lugar establecido.
El sobre podrá ser rotulado de la siguiente manera:
CODIGO DEL PROCESO DE CONTRATACION
YACIMIENTOS PETROLIFEROS FISCALES BOLIVIANOS
NOMBRE DEL PROPONENTE:____________________________________________
NIT DEL PROPONENTE:_________________________________________________
OBJETO DE LA CONTRATACION:
___________________________________________________________________
Retiro de ofertas
17.5.1 Las ofertas presentadas solo podrán retirarse hasta antes del plazo límite establecido para la presentación de ofertas.
Para este propósito el proponente, a través de su Representante Legal, deberá solicitar por escrito la devolución total de su ofertas, que será efectuada bajo constancia escrita y liberando de cualquier responsabilidad a Yacimientos Petrolíferos Fiscales Bolivianos.
Las causales de rechazo son:
Cuando la (s) oferta (s) fuesen presentadas fuera del plazo (fecha y hora) y/o en lugar diferente al establecido en el presente DCD.
APERTURA DE OFERTAS
La apertura de las ofertas será efectuada en acto público por el o los funcionarios integrantes del Comité de Contratación, en la fecha, hora y lugar señalados en el cronograma de plazos.
El acto de apertura será continuo y sin interrupción, donde se permitirá la presencia de los proponentes o de sus representantes que hayan decidido asistir, representantes de la sociedad civil, o personas que quieran participar.
El acto se efectuará así se hubiese recibido una sola oferta.
Durante el Acto de Apertura de ofertas no se descalificará a ningún proponente, siendo esta una atribución del Comité de Contratación, el Comité así como los asistentes deberán abstenerse de emitir criterios o juicios de valor sobre el contenido de las ofertas.
En caso de no existir ofertas, el comité de contratación suspenderá el acto, emitiendo el respectivo informe al RPC.
SECCIÓN VI
EVALUACIÓN Y ADJUDICACIÓN
EVALUACIÓN DE LAS OFERTAS
Concluido el acto de apertura, en sesión reservada el Comité de Contratación procederá a la evaluación de las ofertas presentadas, aplicando el siguiente procedimiento:
Verificación en el SICOES.
Evaluación de las ofertas de acuerdo al método de evaluación establecido en las especificaciones técnicas, cumpliendo el procedimiento establecido en el Manual de Procesos del RE-SABS-EPNE-YPFB
Emisión del Informe de Recomendación al RPC.
En caso de existir aspectos subsanables, el Comité de Contratación solicitará en un determinado plazo sean subsanados los mismos.
DESCALIFICACIÓN DE OFERTAS
Las causales de descalificación son:
Cuando la oferta técnica no cumpla con las condiciones y requisitos establecidos en el presente DCD y las Especificaciones Técnicas.
Cuando la oferta económica exceda el Precio Referencial.
Cuando producto de la revisión aritmética de la oferta económica existiera una diferencia superior al dos por ciento (2%), entre el monto total de la oferta y el monto revisado por el Comité de Contratación, sea esta diferencia positiva o negativa.
Cuando el proponente presente ofertas alternativas en una misma oferta.
Cuando la oferta presente errores no subsanables.
Cuando el proponente, en el plazo establecido no presentara la documentación que será subsanada, el Comité de Contratación, procederá a descalificar la oferta.
Si el proponente adjudicado no presenta la documentación solicitada para la elaboración y firma de contrato u orden de compra, dentro del plazo establecido para su verificación; salvo que el proponente adjudicado hubiese justificado oportunamente el retraso y el RPC autorice la ampliación de plazo para la presentación o complementación de los documentos solicitados.
Cuando el proponente adjudicado desista de forma expresa, tácita o verbal de suscribir el contrato u orden de compra.
En caso de comprobarse falsedad en la información presentada por el proponente.
ERRORES NO SUBSANABLES Y ERRORES SUBSANABLES
Se consideran errores no subsanables, siendo objeto de descalificación, los siguientes:
La falta de presentación del formulario A-1.
La falta de la oferta técnica.
La falta de la oferta económica.
Errores Subsanables
Los errores considerados subsanables deben estar descritos en el informe de evaluación emitido por el Comité de Contratación.
ETAPA DE CONCERTACION
Para procesos mayores a Bs.1.000.000.-, en procura de mejores condiciones técnicas y/o económicas, el Comité de Contratación procederá a la Etapa de Concertación con él o los proponentes cuyas ofertas hubieran cumplido las condiciones del Documento de Contratación Directa, y estén incluidos en el informe Recomendación emitido por del Comité de Contratación.
Cuando se lleve adelante la etapa de concertación, el Comité de Contratación detallará los resultados de esta etapa en un informe final de Recomendación de Adjudicación dirigido al RPC, debiendo expresar las nuevas condiciones técnicas y/o económicas conseguidas para Yacimientos Petrolíferos Fiscales Bolivianos.
ADJUDICACIÓN
La adjudicación será efectuada por el RPC a través de Nota Expresa y notificada al o los proponente (s) ganador (es).
En caso de no adjudicarse el proceso de contratación el RPC, a través de nota, comunicara a la unidad solicitante.
SECCIÓN VII
SUSCRIPCIÓN DE CONTRATO
SUSCRIPCIÓN DE CONTRATO
El o los proponente (s) adjudicado (s), deberá presentar para la suscripción de contrato, los originales, fotocopias simples o fotocopias legalizadas de los documentos señalados en el Formulario A-1.
Los documentos deberán ser presentados en el plazo que establezca la nota de solicitud emitida por Y.P.F.B. Si el proponente adjudicado presentase los documentos antes del tiempo otorgado, el proceso podrá continuar. En casos excepcionales y de manera justificada el proponente podrá solicitar la ampliación de plazo de presentación de los documentos que será aprobado por el RPC.
Si el proponente adjudicado no cumpliese con la presentación de los documentos requeridos para la firma del contrato, se adjudicará a la siguiente oferta mejor evaluada.
MODIFICACIONES AL CONTRATO
Se podrán efectuar modificaciones al contrato de acuerdo a lo establecido en el Reglamento Específico del Sistema de Administración de Bienes y Servicios RE-SABS-EPNE-YPFB.
PARTE II
ESPECIFICACIONES TECNICAS
OBJETO DE LA CONTRATACIÓN
Se espera contar con una solución que incluya los siguientes componentes:
Plataforma integral de Inteligencia operativa
Herramienta de Gestión y Monitoreo de Aplicaciones
Herramienta de Gestión y Monitoreo de Bases de Datos.
Gestión y Monitoreo de Infraestructura
Dispositivo para gestión y análisis de Redes, incluyendo datos históricos.
Todo ello permitirá administrar y gestionar de manera adecuada y precisa todos los recursos que se utilizan en la DNTI y con ello optimizar los servicios hacia el usuario final de la Corporación. La solución también permitirá gestionar de manera más ágil y efectiva los macro proyectos que se encaran en esta dirección, como ser la implementación del ERP Corporativo SAP, seguridad integral de sistemas, etc.
ESPECIFICACIONES TÉCNICAS
ADQUISICIÓN IPM/APM
I.- Especificaciones para APM (Application Performance Management).- |
Instalación e instrumentación, La solución propuesta: |
Deberá proveer Instalación sencilla mediante la Consola de Administración en ambientes del cliente (On-Premise). |
Deberá permitir la Instrumentación automática de métodos y clases. |
Deberá tener la capacidad de que el sistema pueda trabajar en ambientes de desarrollo y también de producción. |
Deberá tener la capacidad de mapeo de capas lógicas durante el proceso de instalación. |
Deberá tener la capacidad de registrar nuevos cambios en la aplicación. |
Deberá tener la capacidad de exportar/importar la configuración del sistema entre diferentes ambientes. |
Descubrimiento de Business Transactions, la solución propuesta: |
Deberá tener la capacidad para descubrir Business Transactions con los métodos Inspect Payload y Code Execution Path o similares. |
Deberá tener la capacidad de Autodescubrimiento de transacciones mediante los Entry Points del flujo de datos. |
Deberá tener la capacidad para definir Exit Point en la interfaz de usuario. |
Deberá tener la capacidad para agrupar Backends automaticamente usando parámetros como por ejemplo: HTTP y JDBC |
Deberá tener la capacidad para inspeccionar urls/headers y agruparlos en transacciones simples |
Traceo de transacción de extremo a extremo, la solución propuesta: |
Deberá tener la capacidad de seguimiento de transacciones de extremo a extremo a través de todos los servicios distribuidos. |
Deberá tener la capacidad de descubrimiento y modelado dinámico de la relación de servicios y back-ends |
Deberá tener la capacidad de representación visual de todas las transacciones distribuidas |
Aprendizaje del comportamiento de desempeño y detección de anomalías. La solución propuesta deberá incluir la: |
Capacidad de aprendizaje del comportamiento normal para cada transacción de datos. |
Capacidad para capturar y establecer líneas base (Baseline) dinámicos para el desempeño normal de todos los niveles y capas de una transacción. |
Capacidad para detectar desviaciones estándar del comportamiento normal de una aplicación. |
Capacidad para definir manualmente los umbrales de desempeño o SLAs para transacciones individuales. |
Capacidad para establecer políticas de tiempos de respuesta y tasa de errores. |
Capacidad de generar alertas cuando un política es incumplida o alterada o modificada. |
Capacidad de iniciar la captura de datos de diagnóstico cuando una política es alterada o modificada. |
Retención de datos de desempeño, la solución propuesta: |
Deberá incluir un Dashboard para mostrar la distribución del tiempo de respuesta a través de los servicios de una transacción. |
Deberá tener la capacidad para conservar datos de desempeño mínimo por 3 años. |
Deberá tener la capacidad para capturar y mostrar cambios de configuración de los servidores de aplicación. |
Captura de datos, la solución propuesta deberá tener: |
Capacidad de captura automática de snapshots cuando algún problema ocurre. |
Capacidad de captura de datos de diagnóstico para cualquier problema (retardo, error, etc). |
Capacidad de generar Snapshots que capturen y muestren datos de diagnóstico a través de todos los servicios y capas. |
Capacidad de generar Snapshots que den visibilidad de cada método y clase que interviene en la transacción. |
Capacidad de generar Snapshots que muestren desempeños relacionados con servidores de aplicación. |
Capacidad de generar snapshots que muestren datos relacionados con el Hardware (CPU, Memoria, I/O) |
Capacidad de generar snapshots que muestren llamadas a bases de datos y cuales toman el mayor tiempo de respuesta. |
Capacidad de generar Snapshots que muestren todos los datos colectados del cliente al momento de la violación de un umbral establecido. |
Capacidad de capturar parámetros HTTP, cookies, y header en un snapshot. |
Capacidad para mostrar y comparar, lado a lado, los Snapshots. |
Capacidad para determinar las llamadas de las bases de datos y los métodos que consumen mayor tiempo a través de múltiples snapshots. |
Disponibilidad para capturar snapshots en intervalos definidos ( no únicamente cuando una política ha sido alterada o modificada ) |
Monitoreo de memoria, la solución propuesta deberá tener la: |
Capacidad de monitoreo del comportamiento de bancos y "Pools" de memoria. |
Capacidad para detectar automáticamente basura y fuga de memoria (memory leaks) |
Capacidad de Visibilidad del código y transacciones que causan problemas de memoria. |
Dashboards & Reportes, la solución propuesta deberá tener la: |
Capacidad de Visibilidad del desempeño de múltiples aplicaciones en un solo dashboard. |
Capacidad de Combinación y correlación datos de desempeño de Aplicaciones, Infraestructura y Business Transactions con Experiencia de Usuario Final en un solo Dashboard. |
Capacidad para personalizar dashboards basados en los roles de usuario. |
Capacidad para crear dashboards con métricas, gráficos personalizados. |
Manejo de Alertas, la solución propuesta deberá tener la: |
Capacidad para definir alertas basadas en la capturas de datos del desempeño de la aplicación. |
Capacidad de generar alertas via Email o SMS. |
Capacidad de Integración con sistemas de seguimiento de incidentes via API. |
Definición de Xxxxxx, la solución propuesta deberá tener la: |
Capacidad para determinar reglas a nivel de aplicación para evaluar tiempos de respuesta y tasa de errores. |
Capacidad para determinar reglas a nivel de "Business Transactions" para evaluar tiempos de respuesta y tasa de errores. |
Capacidad para determinar reglas para evaluar el desempeño de un equipo (CPU, memoria, I/O) |
Capacidad para determinar reglas para evaluar estadísticas y datos recolectados. |
Capacidad para combinar múltiples reglas. |
Capacidad para generar acciones personalizadas en base a la violación de reglas. |
Capacidad para lanzar notificaciones o alertas cuando las reglas son alteradas o modificadas. |
Capacidad para ejecutar workflows cuando una regla ha sido alterada o modificada. |
Capacidad para deshabilitar reglas por un tiempo predefinido. |
Definición de Workflows, la solución propuesta deberá tener la: |
Capacidad para definir un workflow como una serie de actividades a realizar secuencialmente. |
Capacidad para generar una plantilla de actividades predefinidas para los workflows. |
Capacidad para ejecutar tareas, de un workflow, en paralelo. |
Capacidad para crear plantillas personalizadas. |
Capacidad para especificar parámetros de tareas mientras se ejecuta el workflow. |
Capacidad para que los Workflows
se puedan ejecutar: |
Definición de Centros de Cómputo. La solución propuesta deberá tener la: |
Capacidad para definir centros de cómputo: físicos, virtuales o en la nube. |
Capacidad para crear conectores personalizados con parámetros específicos de nube y virtuales. |
La solución Deberá incluir Interfaz Web para la consola de Administración |
|
II.- Solución de APM (Application Performance Management) para bases de datos.- |
Instalación e instrumentación, la solución propuesta deberá tener la: |
Capacidad para instalación en servidores Windows o Linux sin utilización de agentes. |
Capacidad de instalación centralizada para monitorear cualquier combinación de bases de datos. |
Capacidad de No afectar o hacer ningún cambio en las Base de Datos a monitorear. |
Capacidad de ser utilizado en arquitecturas virtuales, físicas y de Nube. |
Traceo de transacción de extremo a extremo, la solución propuesta: |
Deberá proporcionar visibilidad de extremo a extremo desde el usuario final hasta la base de datos. |
Granularidad de datos, la solución propuesta: |
Deberá ser capaz de capturar datos en periodos de tiempo mínimo de 10 segundos |
Soporte para pruebas |
Deberá ser capaz de generar reportes de comparación de pruebas en dos escenarios distintos, señalando claramente los indicadores clave de cada prueba junto con sus diferencias. |
Monitoreo de Producción |
Deberá ser capaz de proporcionar la raíz del problema a través de un proceso automático en vez de revisar manualmente la información de la Base de Datos. |
Deberá permitir monitorear cualquier base de datos o combinación de bases de datos desde una interfaz de web única. |
Capacidad para monitorear las siguientes bases de datos: IBM DB2, MySQL, Oracle, PostgreSQL, SQL Server, Sybase ASE. |
Deberá tener la capacidad para mostrar el rendimiento de cada una de las sentencias SQL y procedimientos almacenados, para cada instancia de la BD, junto con el % de consumo de CPU para cada uno de ellos. |
Deberá proporcionar vistas gráficas del uso de los recursos en el tiempo que permitan visualizar cuándo los recursos del DBMS y del servidor son consumidos por las aplicaciones. |
Deberá permitir hacer análisis comparativos de diferentes periodos de tiempos y/o de diferentes instancias de bases de datos. |
Visibilidad de la Información, La solución deberá proporcionar visibilidad para: |
Sentencias SQL y Procedimientos Almacenados |
Tiempos de Espera |
Consumo de Recursos |
Objetos de la base de datos. |
Estadísticas del Esquema de la BD. |
Sesiones de Usuario |
Archivos de datos (Data Files) |
Eventos de Cambios (Change Events) |
Dashboards & Reportes, la solución ofertada: |
Deberá tener la capacidad de generar dashboards y reportes que muestren: cambios en la utilización del CPU, tiempos de espera y número de ejecuciones de cada sentencia SQL. |
Deberá generar reportes que permitan comparar al menos dos escenarios (i.e. ambiente de producción y ambiente de pruebas). |
Deberá generar vistas completamente configurables para periodos de tiempo mínimo 5 minutos. |
III.- Especificaciones para Herramienta de Gestión del Rendimiento de Infraestructura y Redes .- |
Requerimientos Generales, la solución propuesta deberá tener la: |
Capacidad de análisis rápido de causa raíz de problemas en los servicios actualmente en producción y los que se instalarán a futuro. |
Capacidad de Identificación de forma precisa de qué usuarios, servicios y aplicaciones están consumiendo recursos de infraestructura (redes y servidores) así como ancho xx xxxxx. |
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura (redes y servidores). |
Capacidad de monitoreo a través de una consola o interface web centralizada de por lo menos: |
i) Calidad |
ii) Cumplimiento del comportamiento esperado para los servicios. |
iii) Monitoreo de Redes, Servidores, ambientes físicos, ambientes virtuales |
iv) Tráfico de red |
Capacidad de proveer información del consumo de los recursos de los servicios corporativos . |
Capacidad de análisis de tendencias de comportamiento de los servicios, su relación con elementos de infraestructura y nivel de cumplimiento de Niveles de Servicio (SLAs). |
Capacidad de proveer Tableros de Control desde un solo punto en común (consola) en base a indicadores xx xxxxxx, disponibilidad, tiempos fuera de servicio, tiempos de reparación xx xxxxxx, rendimiento de servicios en el tiempo y análisis de tráfico de Red. |
Capacidad de soporte multi-tecnología, multi-proveedor. (El motor de descubrimiento Deberá ser capaz de descubrir los diferentes dispositivos de comunicaciones e infraestructura por ejemplo: routers, switches, hubs, firewalls,UTMs, balanceadores, servidores, etc., vía por lo menos el protocolo SNMP). |
Capacidad de descubrimiento de dispositivos, mínimo en base a ingreso de direcciones IP, rangos de direcciones IP, importando las direcciones IP desde un archivo plano, etc. |
Capacidad de descubrimiento automático de topología a nivel capa 2 y capa 3 que permita la identificación de cada dispositivo y sus relaciones, vínculos e interdependencias con el resto de los componentes de la infraestructura de acuerdo a los diferentes servicios IP y configuraciones detectados en los routers y switches. |
Capacidad de selección de diferentes métodos de búsqueda, mínimo: consultas de tablas ARP, consultas de tablas de enrutamiento, consultas de tablas de enrutamiento de protocolos propietarios, spanning tree, resolución de tráfico, etc.). |
Capacidad de almacenar configuraciones de descubrimiento (topologías) realizadas. |
Capacidad de mostrar registros históricos en el que se puedan ver los dispositivos nuevos, dispositivos eliminados y cambios con respecto al último descubrimiento. |
Deberá contar con una interface gráfica para representar cualquier problemática detectada en los dispositivos dentro de los mapas topológicos destacando con un color el icono correspondiente al generador de la falla. |
La solución Deberá poseer la capacidad de determinar el origen de la causa raíz de una falla sin que se requiera la creación de reglas de correlación por el administrador, programación ni personalización manual de ningún tipo. |
Como consecuencia del análisis de causa raíz se deberá generar un alarma que indique y proporcione información sobre la falla detectada y su consecuente correlación de eventos. |
El resultante del análisis de causa raíz deberá presentarse en modo visual dentro de los mapas y vistas topológicas, resaltando en algún color específico el componente originador de la falla y en un color diferente, los componentes impactados y afectados por la misma. |
Ante cambios detectados en la topología, el motor de análisis de causa raíz Deberá continuar en funcionamiento sin necesidad de ninguna intervención de configuración / re-configuración manual. |
Las alarmas Deberán proveer información que les permita a los usuarios actuar en consecuencia para resolver el problema (Detección de la sintomatología del problema, causas probables, posibles acciones de reparación). |
Capacidad de análisis de impacto automático que permita valorar el impacto de una falla/alarma en términos de negocio en base a servicios de negocio, usuario o clientes afectados por la falla detectada. |
Deberá proveer algoritmos para la correlación de eventos tanto dinámicos como configurables por los administradores (par de eventos, ráfaga de eventos, condicionales, etc.). |
Capacidad para poder importar alarmas de otras fuentes via traps SNMP o plantillas XML. |
Por lo menos 3 niveles de acceso. Deberá estar definido en base a roles y perfiles de usuario pudiendo el administrador configurar los accesos y permisos. |
Facilidad para que cualquier usuario/rol pueda generar su propia vista de la infraestructura. |
Capacidad de generación de Mapas topológicos unificados en donde se pueda visualizar todos los componentes de la infraestructura, equipos de comunicación y servidores, incluyendo la plataforma virtual con diferenciación mediante íconos específicos para servidores físicos y servidores virtuales. |
Capacidad de correlación de eventos, análisis de causa raíz, aislamientos xx xxxxxx y análisis de impacto unificado para todas las tecnologías solicitadas (redes, servidores, base de datos y plataforma virtual). |
Capacidad de modelado automático de vistas topológicas de la infraestructura en base a descubrimiento automático. |
Capacidad de modelado de cada dispositivo, sus interfaces, puertos físicos y lógicos y la conectividad de estos con el resto de los componentes de la infraestructura. |
Los mapas topológicos generados Deberán representar la infraestructura con iconos específicos para cada tipo de dispositivo en el cual se represente con un esquema de colores o semáforos (rojo, amarillo, verde), el estado de dicho dispositivo y de cada uno de sus componentes asociados (puertos físicos y lógicos, etc.). |
Capacidad de modelamiento de contenedores para agrupar dispositivos de acuerdo a criterios de conectividad (redes, subredes, etc.) o arbitrario (aéreas, sectores, zonas, sedes, etc.). |
Capacidad de visualización en línea de información asociada a cada dispositivo, por ejemplo tablas de ruteo, direccionamiento, interfaces, protocolos propietarios, etc., entre otros. |
Capacidad de aislar un componente del resto de la infraestructura de forma tal de verlo únicamente con los dispositivos directamente conectados. |
Capacidad de modo visual dentro de las mismas vistas topológicas de los diferentes dispositivos asociados a las VLAN detectadas, los diferentes equipos asociados a esquemas de redundancia (primario, secundario, stand-by), etc. |
Capacidad de edición de las vistas topológicas para poder agregar información de contexto (mapas de fondo, etiquetas, sombras, llamadas) que permitan a los usuarios identificar rápidamente el contexto de la información visualizada. |
Capacidad para definir niveles de acuerdo de servicio (SLA) mínimo por disponibilidad, periodo máximo de falla, tiempo promedio entre fallas y tiempo promedio de reparación xx xxxxxx. |
Capacidad para definir reglas de sensibilidad sobre los servicios como ser alta sensibilidad, baja sensibilidad, porcentaje de recursos afectados, redundancia, etc. |
La solución deberá permitir realizar seguimiento en tiempo real de cumplimiento de SLAs |
Capacidad de hacer análisis de tendencias sobre el cumplimiento de los SLAs establecidos. |
Requerimiento para Gestión de Desempeño y Capacidad |
La solución deberá realizar Análisis de tendencias con base en la información histórica para Capacidad de Planeación (Capacity Planning). |
La solución deberá permitir un control proactivo de indicadores clave de rendimiento (KPIs) |
La solución deberá determinar, por cada variable monitoreada, la tendencia de consumo de recursos, y posteriormente realizar un análisis que identifique potenciales problemas ordenándolos por prioridad. |
El sistema deberá ser capaz de calcular para cada muestra capturada el comportamiento normal (o baseline) de dicha variable para el dispositivo en cuestión sin requerir de programación ni personalización alguna. |
Capacidad de detectar degradaciones en la infraestructura antes de que se presenten problemas e indicar gráficamente esta degradación. |
Capacidad de generar alertas en base a desviación del comportamiento o consumo normal (lineas base) de cada una de las variables monitoreadas para las diferentes tecnologías. |
Capacidad de presentación en línea de datos de rendimiento (gráfico y tabular) |
La solución deberá permitir realizar reportes de tendencias de las variables monitoreadas en función de las estadísticas recolectadas. |
La información que suministren los reportes deberá incluir tablas y gráficos que faciliten la visualización de las estadísticas registradas. |
Los reportes deberán ser exportables mínimo a formato HTML, PDF y en un formato estándar susceptible de ser tratado por una planilla de cálculo. |
La solución deberá permitir la generación de reportes para distintos niveles de usuarios: gerenciales, técnicos, etc. |
Capacidad para generar reportes del comportamiento histórico de una o varias variables |
Requerimiento para la gestión de dispositivos de Red |
Capacidad de monitoreo y almacenamiento de la configuración de dispositivos de comunicaciones (routers, switches, firewalls, UTMs, etc.) multi-proveedor (Cisco, Checkpoint, Sun, IBM, HP, DELL, Juniper, y las marcas más conocidas en el mercado boliviano) |
La captura de configuración de los dispositivos Deberá poder realizarse por lo menos mediante alguno de los siguientes protocolos de acceso TFTP, Telnet/FTP, SSH. |
Capacidad de monitoreo de configuraciones y generación de alarmas ante la detección de cambios. |
Capacidad de monitoreo de discrepancias en la configuración de running y startup, además de generación de alarmas. |
Capacidad de visualizar rápidamente y en pantalla los cambios realizados (líneas agregadas, líneas modificadas, líneas eliminadas), ante la detección de cambios en la configuración. |
Capacidad de creación de políticas de contenido de configuración que generen alarmas ante la detección de una configuración que no cumpla con la política. |
Capacidad para automatizar tareas de corrección de configuraciones (upload) ante la detección de un cambio no autorizado o el incumplimiento de una política. |
Capacidad para capturar configuraciones incluyendo dispositivos no certificados. |
Todas las funcionalidades requeridas para la gestión de configuración Deberán poder ser visualizadas y accedidas desde la misma interface de usuario. |
Capacidad para programar tareas de actualización o captura de configuraciones en masa (bulk tasks) en base a calendarios previamente definidos. |
Capacidad para generar reportes relacionados a los cambios de configuración detectados en un periodo determinado de tiempo y sobre un grupo definido de dispositivos. |
Capacidad para soportar procesos
de gestión de cambios implicando flujos de aprobaciones los
cuales pudieran implementarse en la misma solución o mediante la
integración con sistema xx xxxx de ayuda a implementarse a
futuro. |
Capacidad de recolectar información de flujo tipo Cisco NetFlow, S-flow y IPFIX desde múltiples dispositivos en forma simultánea a lo largo de toda la infraestructura de comunicaciones. |
La solución deberá mantener almacenada en su base de datos un mínimo histórico de información de 12 meses. Toda la información histórica almacenada en este repositorio deberá poder ser presentada con una ventana mínima de granularidad de 15 minutos. Los usuarios deberán poder seleccionar cualquier rango de 15 minutos sobre los últimos 12 meses almacenados mostrándose la información correspondiente a la utilización y protocolos para cada interface monitoreada. |
La solución propuesta deberá ser capaz de monitorear y generar reportes sobre un mínimo de 10000 protocolos por día y mostrar información de utilización para cada protocolo en forma individual. Esta característica Deberá estar disponible para cada una de las interfaces monitoreadas. |
El sistema deberá proveer funcionalidades que permitan la fácil ejecución de reportes sobre la información almacenada en su repositorio de largo plazo. La configuración y ejecución de los mismos Deberá estar asistida por interfaces gráficas que guíen a los usuarios. |
Capacidad de creación de reportes de forma tal que los usuarios puedan realizar búsquedas incluyendo todo el tráfico IP para un periodo histórico definido y de acuerdo a diferentes criterios y condiciones. El sistema deberá ser capaz de realizar búsquedas sobre todo el tráfico IP sin pérdidas o exclusiones de ningún tipo de tráfico. |
La solución propuesta deberá ser capaz de detectar en forma automática comportamientos anómalos o no autorizados en aplicaciones. |
Capacidad de agrupación de interfaces de acuerdo a diferentes criterios definidos por el usuario. Los usuarios podrán definir el nombre de los grupos y seleccionar las interfaces incluidas en cada grupo. El generador de reportes podrá ejecutar reportes en base a los grupos definidos. |
Especificaciones para la Solución de Análisis de Redes Retrospectivo |
Requerimientos Generales |
Capacidad para un rápido análisis de la causa raíz de los problemas actualmente en la producción que minimiza el tiempo de inactividad y el impacto en el usuario final. |
Capacidad de Identificación de forma precisa de qué usuarios, servicios y aplicaciones están consumiendo recursos de infraestructura (redes y servidores) así como ancho xx xxxxx. |
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura (redes y servidores). |
Capacidad de proveer información del consumo de los recursos de los servicios corporativos (para ayudar a tomar decisiones acerca de adquisiciones nuevas). |
Capacidad de análisis de tendencias de comportamiento de los servicios, su relación con elementos de infraestructura y nivel de cumplimiento de Niveles de Servicio (SLAs). |
Capacidad para capturar con precisión en las redes totalmente saturados; recoge full-duplex, estadísticas de captura de velocidad de cable; y puede monitorear múltiples enlaces Gigabit. |
Requerimientos para gestión de topologías y fallas. |
Capacidad de captura exportacion de manera sencilla a los dispositivos de seguridad, el cumplimiento y herramientas forenses y otros analizadores de red. |
Capacidad para proporcionar análisis de transacciones de aplicaciones con gran detalle sobre de las capas de 5 a 7 del modelo OSI. |
Capacidad de incorporación de reglas de Snort o equivalentes para investigar las violaciones de seguridad y problemas de cumplimiento. |
Capacidad para proporcionar capacidades de resolución de problemas, con detalles sobre las comunicaciones de voz y vídeo, incluyendo jitter, pérdida de paquetes, y las métricas de puntuación como MOS / OMVs (en conjunto y sobre una base de conexión por conexión). |
Deberá contar con una interface gráfica para representar cualquier problemática detectada en los dispositivos dentro de los mapas topológicos destacando con un color el icono correspondiente al generador de la falla. |
La solución deberá poseer la capacidad de determinar el origen de la causa raíz de una falla sin que sea requerida la creación de reglas de correlación, programación ni personalización manual de ningún tipo. |
Como consecuencia del análisis de causa raíz se deberá generar una única alarma que indique y provea información sobre la falla detectada y su consecuente correlación de eventos. |
Las alarmas Deberán proveer información que les permita a los usuarios actuar en consecuencia para resolver el problema (Detección de la sintomatología del problema, causas probables, posibles acciones de reparación). |
Capacidad de análisis de impacto automático que permita valorar el impacto de una falla/alarma en términos de negocio en base a servicios de negocio, usuario o clientes afectados por la falla detectada. |
Capacidad de que el motor de análisis de causa raíz continúe en funcionamiento sin necesidad de ninguna intervención de configuración / re-configuración manual, ante cambios detectados en la topología |
Capacidad de proveer algoritmos para la correlación de eventos tanto dinámicos como configurables por los administradores (par de eventos, ráfaga de eventos, condicionales, etc.) para permitir la correlación de eventos que no tengan ninguna relación explicita entre ellos. |
Capacidad de generación de Mapas topológicos unificados en donde se pueda visualizar todos los componentes de la infraestructura incluyendo la plataforma virtual con diferenciación mediante íconos específicos para servidores físicos y servidores virtuales. |
Capacidad de correlación de eventos, análisis de causa raíz, aislamientos xx xxxxxx y análisis de impacto unificado para todas las tecnologías solicitadas (redes, servidores, base de datos y plataforma virtual). |
Requerimiento para Gestión de Desempeño y Capacidad |
La solución propuesta deberá concentrar y consolidar en un único repositorio toda la información relacionada a performance capturada de los diferentes componentes tecnológicos incluyendo redes, servidores (físicos y virtuales) y base de datos, etc. |
La solución propuesta deberá realizar Análisis de tendencias con base en la información histórica para Capacity Planning. |
La solución propuesta deberá permitir un control proactivo de indicadores clave de rendimiento (KPIs) |
La solución propuesta deberá ser capaz de determinar, por cada variable monitoreada, la tendencia de consumo de recursos, y posteriormente realizar un análisis que identifique potenciales problemas ordenándolos por prioridad. |
El sistema propuesto deberá ser capaz de calcular para cada muestra capturada el comportamiento normal (o baseline) de dicha variable para el dispositivo en cuestión sin requerir de programación ni personalización alguna. Posteriormente estos patrones normales deberán poder ser utilizados para la generación de alarmas y para tareas de Capacity Planning de los recursos (ej: ancho xx xxxxx IP de un enlace, cpu, memoria física, memoria virtual, paginación, discos, filesystems, etc.).. |
Capacidad de generar alertas en base a desviación del comportamiento o consumo normal de cada una de las variables monitoreadas para las diferentes tecnologías. |
Los reportes de la solución deberán ser personalizables y presentar la información acorde al rol del usuario. |
El tiempo de ventana del reporte deberá ser flexible y configurable, permitiendo reportes diarios, mensuales y anuales, y de valores máximos, mínimos y promedios. |
IV.- Especificaciones para la Plataforma de Inteligencia Operativa |
Requerimientos Generales |
La solución propuesta deberá incluir un esquema de licenciamiento que permita instalar sus componentes de manera ilimitada y de acuerdo con las necesidades de la YPFB durante el periodo de implementación o posterior por así convenir a la Institución. |
La solución propuesta deberá permitir el crecimiento de manera lineal implementando componentes que permitan soportar el crecimiento en la cantidad de datos a analizar o bien en la cantidad de usuarios a consultar y visualizar los datos. |
Requerimientos de Operación |
La solución propuesta deberá incluir mecanismos de tolerancia a fallas y balanceo de cargas incluido en la solución. Se requiere que los datos sean colectados sin perdida en los mismos. |
Capacidad de colectar eventos de los diferentes sistemas utilizando por lo menos los siguientes mecanismos: instalación de agente único de colección, recepción de eventos por syslog, recepción de eventos por SNMP, recepción de eventos del resultado de la ejecución de un programa (script), recepción de eventos de captura de tráfico de protocolos. |
La solución propuesta deberá ser capaz de entender cualquier evento generado por los sistemas de la dirección sin importar su origen, formato o fuente de información. |
La solución propuesta deberá ser capaz de indexar los eventos de modo que se puedan realizar búsquedas por palabras, códigos o frases contenidas en el evento. |
La solución propuesta deberá tener un lenguaje sencillo de utilizar para realizar las búsquedas, este lenguaje deberá permitir búsqueda por palabra, código o frases. |
La solución de centralización de eventos deberá poder ser ejecutada mínimo en las siguientes plataformas: Windows Vista, 7, 8 y 81. (32 y64 bits), Windows 2003, 2003 R2, 2008, 2008 R2, 2012 y 2012 R2 (32 y 64 bits), Linux kernel 2.6 o superior (32 y 64 bits), OSX 10.7 o superior (Intel) |
El agente de colección deberá ser compatible para las siguientes plataformas: Windows Vista, 7, 8 y 81. (32 y64 bits), Windows 2003, 2003 R2, 2008, 2008 R2, 2012 y 2012 R2 (32 y 64 bits), Linux kernel 2.6 o superior (32 y 64 bits), Solaris 10,11 (32 y 64 bits), OSX 10.7 o superior (Intel), FreeBSD 7,8 (32 y 64 bits), freeBDS 9 (64 bits), AIX 6.1 y 7.1, HP-UX11 v2 y v3 (PA-RISC e Itanium) |
Capacidad de soporte multi-tecnología, multi-proveedor. El motor de análisis de datos deberá ser capaz de identificar los diferentes eventos pertenecientes a dispositivos de comunicaciones e infraestructura por ejemplo: routers, switches, hubs, firewall, balanceadores, servidores, etc. |
La solución deberá incluir templates que permitan acelerar la adopción de la captura y entendimiento de los datos, de modo que se puedan crear vistas y reportes de una manera muy eficiente. |
La solución deberá incluir comandos de búsqueda que permitan procesar los datos de una manera ágil, estos comandos también Deberán permitir aplicar funciones estadísticas por campo para tener un mejor entendimiento de los problemas. Otros de los comandos que Deberá tener la solución son comandos predictivos. |
La solución propuesta deberá ser capaz xx xxxx eventos en archivos de texto, leer datos provenientes de puertos TCP o UDP. Deberá poder usar scripts para capturar información relevante así como conectarse a bases de datos a través de conexiones de tipo ODBC. La solución deberá poder exportar el resultado de las búsquedas utilizando ODBC hacia otras herramientas. |
|
La solución propuesta deberá tener la capacidad de integrarse con elementos de geo localización para representar eventos en mapas. |
La solución propuesta deberá contener APIS y mecanismos de integración con las aplicaciones desarrolladas por YPFB. |
Requerimientos de Almacenamiento |
La solución propuesta deberá
permitir la definición de políticas de retención de datos en
al menos tres capas: |
La solución propuesta deberá ser capaz de indexar datos en una tasa de al menos 20000 EPS (Eventos por segundo). |
La solución propuesta deberá indexar los datos a nivel de byte, de modo que se puedan aplicar búsquedas por código, palabra o frase. Deberá incluir mecanismos como reducción de mapas o similares que permitan que el análisis de los datos sea instantáneo. |
El agente de colección deberá ser capaz de entender eventos de aplicaciones desarrolladas por la dirección. En caso de requerir servicios de implementación para entender este tipo xx xxxxxxx Deberá incluirse el costo de este desarrollo. |
El agente de colección de datos Deberá ser capaz de capturar los datos sin importar la plataforma en la que está instalado, el formato de los mismos o su cantidad. Los datos Deberán ser enviados en su formato original y deberá incluir mecanismos de filtrado de datos, compresión y manejo de ancho xx xxxxx. |
Los eventos deberán ser almacenados en el servidor de la solución en su formato original, Deberá contar con mecanismos para validar la integridad de los eventos así como mecanismos que impidan el borrado de los eventos, se deberá permitir el borrado de los eventos solo por los usuarios autorizados. |
La solución propuesta deberá contar con mecanismos de auditoria que permitan identificar las actividades realizadas por los usuarios. |
La solución propuesta deberá contar con mecanismos para aplicar las políticas de retención, se requiere aplicar políticas para mantener eventos que faciliten el análisis de causa raíz, mantener en otra ubicación los eventos que faciliten el análisis histórico (al menos 9 meses) y una capa adicional que permita mantener múltiples años de almacenamiento en cinta o VTL |
La solución propuesta deberá ser capaz de integrarse con los mecanismos de respaldo actuales en YPFB. Se Deberá poder manejar respaldos históricos y diferenciales de los datos. |
Requerimientos de Control de Acceso |
Capacidad de monitoreo a través
de una consola o interface web centralizada que incluya por lo
menos: |
La comunicación entre el agente y la solución de centralización de logs deberá permitir el control de ancho xx xxxxx y el manejo de tráfico cifrado. |
La solución propuesta deberá contener mecanismos de configuración de los agentes de colección de manera centralizada. |
La solución propuesta deberá contar con mecanismos de balanceo y alta disponibilidad integrados y no deberá requerir productos adicionales de otros fabricantes. |
Capacidad de proveer Tableros de Control donde se pueda analizar desde un solo punto en común (consola única) la calidad del servicio que se estén entregando en base a indicadores xx xxxxxx, disponibilidad, tiempos fuera de servicio, tiempos de reparación xx xxxxxx, rendimiento de servicios en el tiempo y análisis de tráfico de Red. |
Capacidad de análisis rápido de causa raíz de problemas en los servicios actualmente en producción y los que se instalarán en los próximos años (para reducir tiempos fuera de servicio). |
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura. |
V.- Especificaciones Adicionales |
Tipo de Solución |
La propuesta debe incluir la capacitación, instalación, configuración, programación (la customización, optimización) y puesta en marcha de la solución requerida, acorde a las especificaciones y necesidades de la red corporativa de YPFB, es decir la solución de la propuesta debe ser de tipo “Llave en mano”. |
Mantenimiento |
El proveedor adjudicado debe realizar actualizaciones así como el mantenimiento de los componentes/módulos de la solución instalada, mientras dure el período de garantía en coordinación con la Dirección Nacional de Tecnologías de la Información y sin costo adicional. |
Experiencia del proveedor |
- El proveedor deberá contar con acreditación certificada por el fabricante de al menos cuatro (4) años de experiencia como proveedor de soluciones de Administración y Gestión de Rendimiento de Aplicaciones. Se debe adjuntar documentación respaldatoria. - El proveedor deberá demostrar haber realizado la implementación de 2 soluciones similares a la ofertada. Se aceptarán como documentación respaldatoria: fotocopias simples de contratos, facturas, certificados, órdenes de compra, de clientes a los que se les ha instalado la solución ofertada o equivalente. - El proveedor deberá demostrar con documentación (fotocopias simples) que cuenta con servicio técnico local autorizado en Bolivia, de la(s) marca(s) ofertada(s). |
Experiencia del personal técnico del proveedor |
El proveedor debe tener entre su personal de planta al menos tres (3) profesionales expertos y con certificación, emitida por el fabricante, en instalación, administración, gestión y solución de problemas de la solución ofertada. Se deben adjuntar las certificaciones de los profesionales. |
Experiencia del proponente en implementaciones |
El proveedor debe tener experiencia en la implementación de soluciones de Administración y gestión de aplicaciones de tipo empresarial. Se debe adjuntar documentación respaldatoria que podrá ser: fotocopias simples de contratos, facturas, certificados, órdenes de compra, de clientes a los que se les ha instalado la solución ofertada o equivalente. |
Transferencia de Conocimientos |
Durante el período de implementación de la solución, el proveedor adjudicado realizará la transferencia de conocimientos mediante actividades que permitan al personal designado por la Dirección Nacional de Tecnologías de la Información administrar, mantener y soportar todas las funcionalidades de hardware y software del sistema implementado. |
Manuales |
Se deben incluir al momento de la entrega manuales técnicos, de instalación, de usuario y documentos adicionales de las soluciones ofertadas en medio impreso y/o digital. |
Inspección y Pruebas |
El proveedor, de acuerdo a lo solicitado en puntos anteriores, debe establecer un calendario para realizar pruebas de programación (verificación en la configuración inicial, módulos, plantillas, etc.), adquisición de datos, monitoreo del sistema instalado coordinando con funcionarios de la DNTI. |
Plazos de entrega |
El tiempo de entrega de las
licencias será máximo de 15 días calendario a partir de la
firma del contrato. No se aceptaran entregas parciales. |
Garantía Técnica |
El proveedor adjudicado debe presentar una garantía de fábrica vigente por un periodo de tres (3) años a partir de la fecha de entrega de las soluciones ofertadas que debe incluir mano de obra, costos de atención en sitio donde se encuentre instalado el sistema, actualizaciones de versión de software. La modalidad de la garantía de fábrica debe ser 7x24. La garantía debe incluir soporte técnico remoto del fabricante mediante la apertura de casos en la web. |
Lugar de Entrega |
Las licencias solicitadas deberán ser entregadas en la Xxxxx xxxxx # 000, Xxxxxxxx xxxxxxx de YPFB para las respectivas pruebas. |
Método de Selección |
Precio Evaluado más bajo |
Forma de Adjudicación |
Por el total |
Validez de la Propuesta |
Las propuestas deben tener un tiempo de validez de por lo menos sesenta (60) días calendario, desde la fecha de presentación de propuestas. |
Forma de Pago |
El pago se realizará a través del SIGMA, contra entrega total de los equipos, una vez que el comité de Recepción designado para el efecto, haya emitido el informe de conformidad, debiendo el proveedor emitir la factura correspondiente a nombre de YPFB con NIT 1020269020. (Manifestar Aceptación) |
Vigencia del Contrato |
El contrato establecido con la empresa proponente que se adjudique el proceso tendrá vigencia a partir del siguiente día hábil desde de la firma del mismo. (Manifestar Aceptación) |
Multas |
El PROVEEDOR se obligará a
cumplir con el plazo de entrega de los bienes, caso contrario
será multado con el 1 % sobre el importe total de la
adjudicación por día calendario de retraso. En caso de llegar
al veinte por ciento (20%) del monto total del contrato, el
contrato será resuelto quedando la adjudicación sin efecto, y
la empresa YPFB se reserva el derecho de realizar las gestiones
legales y administrativas que correspondan. |
Garantía de cumplimiento del contrato |
El proveedor adjudicado deberá presentar una boleta de garantía de cumplimiento de contrato por el 7% del precio original de carácter renovable, irrevocable y de ejecución inmediata a nombre de YPFB. La vigencia de esta garantía deberá exceder en 60 días calendario el plazo estimado de entrega total de los bienes. |
Precio Referencial |
El precio referencial total es de Bs. 2.272.440,00.- (Dos Millones Discientos Setenta y Dos Mil Cuatrocientos Cuarenta 00/100) Bolivianos. |
Anticipo |
En el presente proceso de contratación no se otorgará Anticipo. (Manifestar Aceptación) |
PARTE III
FORMULARIOS DE PRESENTACION
DETALLE DE FORMULARIOS DE PRESENTACIÓN OBLIGATORIA CON LA OFERTA
Documentos Legales y Administrativos
Formulario A-1 Carta de presentación de la Oferta.
Documentos de la Oferta Económica
Formulario B-1 Oferta Económica.
Documentos de la Oferta Técnica
Formulario C-1 Oferta Técnicas.
FORMULARIO A-1
PRESENTACIÓN DE OFERTA
(Para Empresas o Asociaciones Accidentales)
1. DATOS DEL OBJETO DE LA CONTRATACIÓN |
|||||||||||||||||||||
|
|
|
|
|
|
||||||||||||||||
SEÑALAR EL OBJETO DE LA CONTRATACIÓN: |
|
|
|
||||||||||||||||||
|
|
|
|
|
|
||||||||||||||||
VALIDEZ DE LA OFERTA |
|
|
|
||||||||||||||||||
|
|
|
|
|
|
||||||||||||||||
2. DATOS GENERALES DEL PROPONENTE REPRESENTANTE LEGAL |
|||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
Tipo de Proponente: |
|
Unipersonal |
|
Asoc. Accidental |
|
Otro: (Señalar) |
|
||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
Razón Social o Denominación de la Asociación Accidental: |
|
|
|||||||||||||||||||
|
|
Apellido Paterno |
|
Apellido Materno |
|
Nombre(s) |
|
C.I. |
|
||||||||||||
Nombre del Representante Legal |
|
|
|
|
|
|
|
|
|
||||||||||||
Asociados |
: |
NIT |
|
Nombre del Asociado |
|
% de Participación |
|
||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|||||||||||||||
|
|
|
|
|
|
|
|||||||||||||||
|
|
|
|
|
|
|
|||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
Número de Testimonio |
|
Lugar |
|
|
Fecha de Expedición |
|
|
||||||||||||
|
|
|
|
|
(Día |
|
mes |
|
Año) |
|
|
||||||||||
Testimonio de Constitución |
: |
|
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
Dirección |
|
Teléfono/fax |
|
|
|
|
|
||||||||||||
|
|
|
|
|
Correo Electrónico
|
|
NIT |
|
|||||||||||||
Detalle de la empresa o asociación |
: |
|
|
|
|
|
|
|
|
||||||||||||
- Declaro en calidad de Representante Legal contar con un poder general amplio y suficiente con facultades para presentar ofertas y suscribir Contrato (Suprimir este texto cuando el proponente sea una empresa unipersonal y éste no acredite a un Representante Legal). |
|
||||||||||||||||||||
- Declaro que el poder del Representante Legal se encuentra inscrito en el Registro de Comercio. (Suprimir este texto cuando por la naturaleza jurídica del proponente no se requiera la inscripción en el Registro de Comercio de Bolivia y cuando el proponente sea una empresa unipersonal y éste no acredite a un Representante Legal). |
|
A nombre de (Nombre del proponente) a la cual represento, remito la presente oferta declarando expresamente mi conformidad y compromiso de cumplimiento, conforme con los siguientes puntos:
I.- De las Condiciones del Proceso
Declaro cumplir estrictamente la normativa de la Ley N° 1178, de Administración y Control Gubernamentales, lo establecido en el RE-SABS-EPNE-YPFB y el presente DCD.
Declaro no tener conflicto de intereses.
Declaro, que como proponente, no me encuentro en las causales de impedimento, establecidas en numeral 3 de DCD.
Declaro y garantizo haber examinado el DCD, así como los Formularios para la presentación de la oferta, aceptando sin reservas todas las estipulaciones en dichos documentos y la adhesión al texto del contrato.
Declaro respetar el desempeño de los servidores públicos asignados, por la entidad convocante y no incurrir en relacionamiento que no sea a través de medio escrito, salvo en los actos de carácter público y exceptuando las consultas efectuadas al encargado de atender consultas, de manera previa a la presentación de ofertas.
Declaro la veracidad de toda la información proporcionada y autorizo mediante la presente, para que en caso de ser adjudicado, cualquier persona natural o jurídica, suministre a los representantes autorizados de la entidad convocante, toda la información que requieran para verificar la documentación que presento. En caso de comprobarse falsedad en la misma, la entidad convocante tiene el derecho a descalificar la presente oferta
Declaro haber realizado la Inspección Previa (no corresponde).
Me comprometo a denunciar por escrito, ante la MAE de YPFB cualquier tipo de presión o intento de extorsión de parte de los servidores públicos de la YPFB o de otras personas, para que se asuman las acciones legales y administrativas correspondientes.
II.- De la Presentación de Documentos
En caso de ser adjudicado, para la suscripción de contrato, Orden de Compra, se presentará la siguiente documentación en original o fotocopia legalizada, salvo aquella documentación cuya información se encuentre consignada en el Certificado xxx XXXX, aceptando que el incumplimiento es causal de descalificación de la oferta. Y en caso de Asociaciones Accidentales, lo señalada en el inciso f).
DOCUMENTOS REQUERIDOS PARA ELABORACION DE LA ORDEN DE COMPRA
Certificado xxx XXXX que respalde la información declarada en su oferta, su validez estará sujeta a verificación. (para contrataciones con precio referencial mayor a Bs.20.000.-).
Poder General del Representante Legal del proponente (o su equivalente) con facultades para suscribir contratos. Aquellas empresas unipersonales que no acrediten a un Representante Legal, no deberán presentar este Poder.
Certificado electrónico o fotocopia simple del Certificado de inscripción en el Padrón Nacional de Contribuyentes (NIT) vigente.
Fotocopia simple del Certificado de No Adeudo por Contribuciones al Seguro Social Obligatorio de largo plazo y al Sistema Integral de Pensiones (Resolución Administrativa APS/DPC/DJ/No.551-2013 de 18 xx xxxxx de 2013).
Cuando el empleador tiene a sus dependientes registrados en una sola AFP, deberá presentar el certificado de no adeudo CNA emitido por dicha administradora y el documento de no registro emitido por la otra AFP.
Cuando el empleador tiene a sus dependientes registrados en ambas AFP’s deberá presentar los certificados de no adeudo emitidos tanto por Futuro de Bolivia S.A. como por BBVA previsión AFP S.A.
No es sujeto de contrataciones de bienes y servicios para el Estado, el empleador que presentare el documento de NO REGISTRO de ambas AFP’s
Garantía de Cumplimiento de Contrato equivalente al siete por ciento (7%) del monto del contrato. En el caso de Asociaciones Accidentales esta garantía podrá ser presentada por una o más empresas que conforman la Asociación, siempre y cuando cumpla con las características de renovable, irrevocable y de ejecución inmediata; emitida a nombre de la entidad convocante. . (Cuando corresponda)
Testimonio de Contrato de Asociación Accidental. (Cuando corresponda)
DOCUMENTOS REQUERIDOS PARA LA ELABORACION DE CONTRATO
Además de los mencionados en el punto i) las empresas deberán presentar los siguientes documentos.
Documento de Constitución de la empresa (o su equivalente), excepto aquellas empresas que se encuentran inscritas en el Registro de Comercio.
Matricula de Comercio actualizada (o su equivalente), excepto para proponentes cuya normativa legal inherente a su constitución así lo prevea.
Certificado de Solvencia Fiscal, emitido por la Contraloría General del Estado (CGE) (para contrataciones con precio referencial mayor a Bs.1.000.000.-),
Fotocopia simple del Balance General y Estados de Resultados de la última gestión fiscal con sello del SIN, excepto las empresas de reciente creación, para contrataciones con precio referencial mayor a Bs.1.000.000.-
(Firma del proponente)
(Nombre completo del proponente)
FORMULARIO Nº B-1
OFERTA ECONÓMICA
DATOS PARA SER LLENADOS POR EL PROPONENTE |
||||
Nº |
DETALLE DEL O LOS BIENES SOLICITADOS |
CANTIDAD |
PRECIO UNITARIO (Bs.) |
PRECIO TOTAL (Bs.) |
1. |
ADQUISICION DE IPM/APM |
1 |
|
|
TOTAL BOLIVIANOS |
|
|||
TOTAL LITERAL |
|
(Firma del proponente)
(Nombre completo del proponente)
FORMULARIO C-1
ESPECIFICACIONES TECNICAS
Descripción de las Especificaciones Técnicas |
Para ser llenado por el proponente al momento de elaborar su oferta |
Evaluación (para ser llenado por el personal técnico del Comité de Contratación) |
||
Característica Solicitadas del Bien |
Característica Ofertadas |
CUMPLE |
NO CUMPLE |
OBSERVACIÓN (porque no cumple) |
I.- ESPECIFICACIONES PARA APM (APPLICATION PERFORMANCE MANAGEMENT).- |
|
|
|
|
INSTALACION E INSTRUMENTACION, LA SOLUCION PROPUESTA: |
|
|
|
|
Deberá proveer Instalación sencilla mediante la Consola de Administración en ambientes del cliente (On-Premise). |
|
|
|
|
Deberá permitir la Instrumentación automática de métodos y clases. |
|
|
|
|
Deberá tener la capacidad de que el sistema pueda trabajar en ambientes de desarrollo y también de producción. |
|
|
|
|
Deberá tener la capacidad de mapeo de capas lógicas durante el proceso de instalación. |
|
|
|
|
Deberá tener la capacidad de registrar nuevos cambios en la aplicación. |
|
|
|
|
Deberá tener la capacidad de exportar/importar la configuración del sistema entre diferentes ambientes. |
|
|
|
|
DESCUBRIMIENTO DFE BUSINESS TRANSACTIONS, LA SOLUCION PROPUESTA |
|
|
|
|
Deberá tener la capacidad para descubrir Business Transactions con los métodos Inspect Payload y Code Execution Path o similares. |
|
|
|
|
Deberá tener la capacidad de Autodescubrimiento de transacciones mediante los Entry Points del flujo de datos. |
|
|
|
|
Deberá tener la capacidad para definir Exit Point en la interfaz de usuario. |
|
|
|
|
Deberá tener la capacidad para agrupar Backends automaticamente usando parámetros como por ejemplo: HTTP y JDBC |
|
|
|
|
Deberá tener la capacidad para inspeccionar urls/headers y agruparlos en transacciones simples |
|
|
|
|
TRACEO DE TRANSACCION DE EXTREMO A EXTREMO, LA SOLUCION PROPUESTA: |
|
|
|
|
Deberá tener la capacidad de seguimiento de transacciones de extremo a extremo a través de todos los servicios distribuidos. |
|
|
|
|
Deberá tener la capacidad de descubrimiento y modelado dinámico de la relación de servicios y back-ends |
|
|
|
|
Deberá tener la capacidad de representación visual de todas las transacciones distribuidas |
|
|
|
|
APRENDIZAJE DEL COMPORTAMIENTO DE DESEMPEÑO Y DETECCIÓN DE ANOMALÍAS. LA SOLUCIÓN PROPUESTA DEBERÁ INCLUIR LA: |
|
|
|
|
Capacidad de aprendizaje del comportamiento normal para cada transacción de datos. |
|
|
|
|
Capacidad para capturar y establecer líneas base (Baseline) dinámicos para el desempeño normal de todos los niveles y capas de una transacción. |
|
|
|
|
Capacidad para detectar desviaciones estándar del comportamiento normal de una aplicación. |
|
|
|
|
Capacidad para definir manualmente los umbrales de desempeño o SLAs para transacciones individuales. |
|
|
|
|
Capacidad para establecer políticas de tiempos de respuesta y tasa de errores. |
|
|
|
|
Capacidad de generar alertas cuando un política es incumplida o alterada o modificada. |
|
|
|
|
Capacidad de iniciar la captura de datos de diagnóstico cuando una política es alterada o modificada. |
|
|
|
|
RETENCIÓN DE DATOS DE DESEMPEÑO, LA SOLUCIÓN PROPUESTA: |
|
|
|
|
Deberá incluir un Dashboard para mostrar la distribución del tiempo de respuesta a través de los servicios de una transacción. |
|
|
|
|
Deberá tener la capacidad para conservar datos de desempeño mínimo por 3 años. |
|
|
|
|
Deberá tener la capacidad para capturar y mostrar cambios de configuración de los servidores de aplicación. |
|
|
|
|
CAPTURA DE DATOS, LA SOLUCIÓN PROPUESTA DEBERÁ TENER: |
|
|
|
|
Capacidad de captura automática de snapshots cuando algún problema ocurre. |
|
|
|
|
Capacidad de captura de datos de diagnóstico para cualquier problema (retardo, error, etc). |
|
|
|
|
Capacidad de generar Snapshots que capturen y muestren datos de diagnóstico a través de todos los servicios y capas. |
|
|
|
|
Capacidad de generar Snapshots que den visibilidad de cada método y clase que interviene en la transacción. |
|
|
|
|
Capacidad de generar Snapshots que muestren desempeños relacionados con servidores de aplicación. |
|
|
|
|
Capacidad de generar snapshots que muestren datos relacionados con el Hardware (CPU, Memoria, I/O) |
|
|
|
|
Capacidad de generar snapshots que muestren llamadas a bases de datos y cuales toman el mayor tiempo de respuesta. |
|
|
|
|
Capacidad de generar Snapshots que muestren todos los datos colectados del cliente al momento de la violación de un umbral establecido. |
|
|
|
|
Capacidad de capturar parámetros HTTP, cookies, y header en un snapshot. |
|
|
|
|
Capacidad para mostrar y comparar, lado a lado, los Snapshots. |
|
|
|
|
Capacidad para determinar las llamadas de las bases de datos y los métodos que consumen mayor tiempo a través de múltiples snapshots. |
|
|
|
|
Disponibilidad para capturar snapshots en intervalos definidos ( no únicamente cuando una política ha sido alterada o modificada ) |
|
|
|
|
MONITOREO DE MEMORIA, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad de monitoreo del comportamiento de bancos y "Pools" de memoria. |
|
|
|
|
Capacidad para detectar automáticamente basura y fuga de memoria (memory leaks) |
|
|
|
|
Capacidad de Visibilidad del código y transacciones que causan problemas de memoria. |
|
|
|
|
DASHBOARDS & REPORTES, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad de Visibilidad del desempeño de múltiples aplicaciones en un solo dashboard. |
|
|
|
|
Capacidad de Combinación y correlación datos de desempeño de Aplicaciones, Infraestructura y Business Transactions con Experiencia de Usuario Final en un solo Dashboard. |
|
|
|
|
Capacidad para personalizar dashboards basados en los roles de usuario. |
|
|
|
|
Capacidad para crear dashboards con métricas, gráficos personalizados. |
|
|
|
|
MANEJO DE ALERTAS, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad para definir alertas basadas en la capturas de datos del desempeño de la aplicación. |
|
|
|
|
Capacidad de generar alertas via Email o SMS. |
|
|
|
|
Capacidad de Integración con sistemas de seguimiento de incidentes via API. |
|
|
|
|
DEFINICIÓN DE REGLAS, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad para determinar reglas a nivel de aplicación para evaluar tiempos de respuesta y tasa de errores. |
|
|
|
|
Capacidad para determinar reglas a nivel de "Business Transactions" para evaluar tiempos de respuesta y tasa de errores. |
|
|
|
|
Capacidad para determinar reglas para evaluar el desempeño de un equipo (CPU, memoria, I/O) |
|
|
|
|
Capacidad para determinar reglas para evaluar estadísticas y datos recolectados. |
|
|
|
|
Capacidad para combinar múltiples reglas. |
|
|
|
|
Capacidad para generar acciones personalizadas en base a la violación de reglas. |
|
|
|
|
Capacidad para lanzar notificaciones o alertas cuando las reglas son alteradas o modificadas. |
|
|
|
|
Capacidad para ejecutar workflows cuando una regla ha sido alterada o modificada. |
|
|
|
|
Capacidad para deshabilitar reglas por un tiempo predefinido. |
|
|
|
|
DEFINICIÓN DE WORKFLOWS, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad para definir un workflow como una serie de actividades a realizar secuencialmente. |
|
|
|
|
Capacidad para generar una plantilla de actividades predefinidas para los workflows. |
|
|
|
|
Capacidad para ejecutar tareas, de un workflow, en paralelo. |
|
|
|
|
Capacidad para crear plantillas personalizadas. |
|
|
|
|
Capacidad para especificar parámetros de tareas mientras se ejecuta el workflow. |
|
|
|
|
Capacidad para que los Workflows
se puedan ejecutar: |
|
|
|
|
DEFINICIÓN DE CENTROS DE CÓMPUTO. LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad para definir centros de cómputo: físicos, virtuales o en la nube. |
|
|
|
|
Capacidad para crear conectores personalizados con parámetros específicos de nube y virtuales. |
|
|
|
|
La solución Deberá incluir Interfaz Web para la consola de Administración |
|
|
|
|
II.- SOLUCIÓN DE APM (APPLICATION PERFORMANCE MANAGEMENT) PARA BASES DE DATOS.- |
|
|
|
|
INSTALACIÓN E INSTRUMENTACIÓN, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad para instalación en servidores Windows o Linux sin utilización de agentes. |
|
|
|
|
Capacidad de instalación centralizada para monitorear cualquier combinación de bases de datos. |
|
|
|
|
Capacidad de No afectar o hacer ningún cambio en las Base de Datos a monitorear. |
|
|
|
|
Capacidad de ser utilizado en arquitecturas virtuales, físicas y de Nube. |
|
|
|
|
TRACEO DE TRANSACCIÓN DE EXTREMO A EXTREMO, LA SOLUCIÓN PROPUESTA: |
|
|
|
|
Deberá proporcionar visibilidad de extremo a extremo desde el usuario final hasta la base de datos. |
|
|
|
|
GRANULARIDAD DE DATOS, LA SOLUCIÓN PROPUESTA: |
|
|
|
|
Deberá ser capaz de capturar datos en periodos de tiempo mínimo de 10 segundos |
|
|
|
|
SOPORTE PARA PRUEBAS |
|
|
|
|
Deberá ser capaz de generar reportes de comparación de pruebas en dos escenarios distintos, señalando claramente los indicadores clave de cada prueba junto con sus diferencias. |
|
|
|
|
MONITOREO DE PRODUCCIÓN |
|
|
|
|
Deberá ser capaz de proporcionar la raíz del problema a través de un proceso automático en vez de revisar manualmente la información de la Base de Datos. |
|
|
|
|
Deberá permitir monitorear cualquier base de datos o combinación de bases de datos desde una interfaz de web única. |
|
|
|
|
Capacidad para monitorear las siguientes bases de datos: IBM DB2, MySQL, Oracle, PostgreSQL, SQL Server, Sybase ASE. |
|
|
|
|
Deberá tener la capacidad para mostrar el rendimiento de cada una de las sentencias SQL y procedimientos almacenados, para cada instancia de la BD, junto con el % de consumo de CPU para cada uno de ellos. |
|
|
|
|
Deberá proporcionar vistas gráficas del uso de los recursos en el tiempo que permitan visualizar cuándo los recursos del DBMS y del servidor son consumidos por las aplicaciones. |
|
|
|
|
Deberá permitir hacer análisis comparativos de diferentes periodos de tiempos y/o de diferentes instancias de bases de datos. |
|
|
|
|
VISIBILIDAD DE LA INFORMACIÓN, LA SOLUCIÓN DEBERÁ PROPORCIONAR VISIBILIDAD PARA: |
|
|
|
|
Sentencias SQL y Procedimientos Almacenados |
|
|
|
|
Tiempos de Espera |
|
|
|
|
Consumo de Recursos |
|
|
|
|
Objetos de la base de datos. |
|
|
|
|
Estadísticas del Esquema de la BD. |
|
|
|
|
Sesiones de Usuario |
|
|
|
|
Archivos de datos (Data Files) |
|
|
|
|
Eventos de Cambios (Change Events) |
|
|
|
|
DASHBOARDS & REPORTES, LA SOLUCIÓN OFERTADA: |
|
|
|
|
Deberá tener la capacidad de generar dashboards y reportes que muestren: cambios en la utilización del CPU, tiempos de espera y número de ejecuciones de cada sentencia SQL. |
|
|
|
|
Deberá generar reportes que permitan comparar al menos dos escenarios (i.e. ambiente de producción y ambiente de pruebas). |
|
|
|
|
Deberá generar vistas completamente configurables para periodos de tiempo mínimo 5 minutos. |
|
|
|
|
III.- ESPECIFICACIONES PARA HERRAMIENTA DE GESTIÓN DEL RENDIMIENTO DE INFRAESTRUCTURA Y REDES .- |
|
|
|
|
REQUERIMIENTOS GENERALES, LA SOLUCIÓN PROPUESTA DEBERÁ TENER LA: |
|
|
|
|
Capacidad de análisis rápido de causa raíz de problemas en los servicios actualmente en producción y los que se instalarán a futuro. |
|
|
|
|
Capacidad de Identificación de forma precisa de qué usuarios, servicios y aplicaciones están consumiendo recursos de infraestructura (redes y servidores) así como ancho xx xxxxx. |
|
|
|
|
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura (redes y servidores). |
|
|
|
|
Capacidad de monitoreo a través de una consola o interface web centralizada de por lo menos: |
|
|
|
|
i) Calidad |
|
|
|
|
ii) Cumplimiento del comportamiento esperado para los servicios. |
|
|
|
|
iii) Monitoreo de Redes, Servidores, ambientes físicos, ambientes virtuales |
|
|
|
|
iv) Tráfico de red |
|
|
|
|
Capacidad de proveer información del consumo de los recursos de los servicios corporativos . |
|
|
|
|
Capacidad de análisis de tendencias de comportamiento de los servicios, su relación con elementos de infraestructura y nivel de cumplimiento de Niveles de Servicio (SLAs). |
|
|
|
|
Capacidad de proveer Tableros de Control desde un solo punto en común (consola) en base a indicadores xx xxxxxx, disponibilidad, tiempos fuera de servicio, tiempos de reparación xx xxxxxx, rendimiento de servicios en el tiempo y análisis de tráfico de Red. |
|
|
|
|
Capacidad de soporte multi-tecnología, multi-proveedor. (El motor de descubrimiento Deberá ser capaz de descubrir los diferentes dispositivos de comunicaciones e infraestructura por ejemplo: routers, switches, hubs, firewalls,UTMs, balanceadores, servidores, etc., vía por lo menos el protocolo SNMP). |
|
|
|
|
Capacidad de descubrimiento de dispositivos, mínimo en base a ingreso de direcciones IP, rangos de direcciones IP, importando las direcciones IP desde un archivo plano, etc. |
|
|
|
|
Capacidad de descubrimiento automático de topología a nivel capa 2 y capa 3 que permita la identificación de cada dispositivo y sus relaciones, vínculos e interdependencias con el resto de los componentes de la infraestructura de acuerdo a los diferentes servicios IP y configuraciones detectados en los routers y switches. |
|
|
|
|
Capacidad de selección de diferentes métodos de búsqueda, mínimo: consultas de tablas ARP, consultas de tablas de enrutamiento, consultas de tablas de enrutamiento de protocolos propietarios, spanning tree, resolución de tráfico, etc.). |
|
|
|
|
Capacidad de almacenar configuraciones de descubrimiento (topologías) realizadas. |
|
|
|
|
Capacidad de mostrar registros históricos en el que se puedan ver los dispositivos nuevos, dispositivos eliminados y cambios con respecto al último descubrimiento. |
|
|
|
|
Deberá contar con una interface gráfica para representar cualquier problemática detectada en los dispositivos dentro de los mapas topológicos destacando con un color el icono correspondiente al generador de la falla. |
|
|
|
|
La solución Deberá poseer la capacidad de determinar el origen de la causa raíz de una falla sin que se requiera la creación de reglas de correlación por el administrador, programación ni personalización manual de ningún tipo. |
|
|
|
|
Como consecuencia del análisis de causa raíz se deberá generar un alarma que indique y proporcione información sobre la falla detectada y su consecuente correlación de eventos. |
|
|
|
|
El resultante del análisis de causa raíz deberá presentarse en modo visual dentro de los mapas y vistas topológicas, resaltando en algún color específico el componente originador de la falla y en un color diferente, los componentes impactados y afectados por la misma. |
|
|
|
|
Ante cambios detectados en la topología, el motor de análisis de causa raíz Deberá continuar en funcionamiento sin necesidad de ninguna intervención de configuración / re-configuración manual. |
|
|
|
|
Las alarmas Deberán proveer información que les permita a los usuarios actuar en consecuencia para resolver el problema (Detección de la sintomatología del problema, causas probables, posibles acciones de reparación). |
|
|
|
|
Capacidad de análisis de impacto automático que permita valorar el impacto de una falla/alarma en términos de negocio en base a servicios de negocio, usuario o clientes afectados por la falla detectada. |
|
|
|
|
Deberá proveer algoritmos para la correlación de eventos tanto dinámicos como configurables por los administradores (par de eventos, ráfaga de eventos, condicionales, etc.). |
|
|
|
|
Capacidad para poder importar alarmas de otras fuentes via traps SNMP o plantillas XML. |
|
|
|
|
Por lo menos 3 niveles de acceso. Deberá estar definido en base a roles y perfiles de usuario pudiendo el administrador configurar los accesos y permisos. |
|
|
|
|
Facilidad para que cualquier usuario/rol pueda generar su propia vista de la infraestructura. |
|
|
|
|
Capacidad de generación de Mapas topológicos unificados en donde se pueda visualizar todos los componentes de la infraestructura, equipos de comunicación y servidores, incluyendo la plataforma virtual con diferenciación mediante íconos específicos para servidores físicos y servidores virtuales. |
|
|
|
|
Capacidad de correlación de eventos, análisis de causa raíz, aislamientos xx xxxxxx y análisis de impacto unificado para todas las tecnologías solicitadas (redes, servidores, base de datos y plataforma virtual). |
|
|
|
|
Capacidad de modelado automático de vistas topológicas de la infraestructura en base a descubrimiento automático. |
|
|
|
|
Capacidad de modelado de cada dispositivo, sus interfaces, puertos físicos y lógicos y la conectividad de estos con el resto de los componentes de la infraestructura. |
|
|
|
|
Los mapas topológicos generados Deberán representar la infraestructura con iconos específicos para cada tipo de dispositivo en el cual se represente con un esquema de colores o semáforos (rojo, amarillo, verde), el estado de dicho dispositivo y de cada uno de sus componentes asociados (puertos físicos y lógicos, etc.). |
|
|
|
|
Capacidad de modelamiento de contenedores para agrupar dispositivos de acuerdo a criterios de conectividad (redes, subredes, etc.) o arbitrario (aéreas, sectores, zonas, sedes, etc.). |
|
|
|
|
Capacidad de visualización en línea de información asociada a cada dispositivo, por ejemplo tablas de ruteo, direccionamiento, interfaces, protocolos propietarios, etc., entre otros. |
|
|
|
|
Capacidad de aislar un componente del resto de la infraestructura de forma tal de verlo únicamente con los dispositivos directamente conectados. |
|
|
|
|
Capacidad de modo visual dentro de las mismas vistas topológicas de los diferentes dispositivos asociados a las VLAN detectadas, los diferentes equipos asociados a esquemas de redundancia (primario, secundario, stand-by), etc. |
|
|
|
|
Capacidad de edición de las vistas topológicas para poder agregar información de contexto (mapas de fondo, etiquetas, sombras, llamadas) que permitan a los usuarios identificar rápidamente el contexto de la información visualizada. |
|
|
|
|
Capacidad para definir niveles de acuerdo de servicio (SLA) mínimo por disponibilidad, periodo máximo de falla, tiempo promedio entre fallas y tiempo promedio de reparación xx xxxxxx. |
|
|
|
|
Capacidad para definir reglas de sensibilidad sobre los servicios como ser alta sensibilidad, baja sensibilidad, porcentaje de recursos afectados, redundancia, etc. |
|
|
|
|
La solución deberá permitir realizar seguimiento en tiempo real de cumplimiento de SLAs |
|
|
|
|
Capacidad de hacer análisis de tendencias sobre el cumplimiento de los SLAs establecidos. |
|
|
|
|
REQUERIMIENTO PARA GESTIÓN DE DESEMPEÑO Y CAPACIDAD |
|
|
|
|
La solución deberá realizar Análisis de tendencias con base en la información histórica para Capacidad de Planeación (Capacity Planning). |
|
|
|
|
La solución deberá permitir un control proactivo de indicadores clave de rendimiento (KPIs) |
|
|
|
|
La solución deberá determinar, por cada variable monitoreada, la tendencia de consumo de recursos, y posteriormente realizar un análisis que identifique potenciales problemas ordenándolos por prioridad. |
|
|
|
|
El sistema deberá ser capaz de calcular para cada muestra capturada el comportamiento normal (o baseline) de dicha variable para el dispositivo en cuestión sin requerir de programación ni personalización alguna. |
|
|
|
|
Capacidad de detectar degradaciones en la infraestructura antes de que se presenten problemas e indicar gráficamente esta degradación. |
|
|
|
|
Capacidad de generar alertas en base a desviación del comportamiento o consumo normal (lineas base) de cada una de las variables monitoreadas para las diferentes tecnologías. |
|
|
|
|
Capacidad de presentación en línea de datos de rendimiento (gráfico y tabular) |
|
|
|
|
La solución deberá permitir realizar reportes de tendencias de las variables monitoreadas en función de las estadísticas recolectadas. |
|
|
|
|
La información que suministren los reportes deberá incluir tablas y gráficos que faciliten la visualización de las estadísticas registradas. |
|
|
|
|
Los reportes deberán ser exportables mínimo a formato HTML, PDF y en un formato estándar susceptible de ser tratado por una planilla de cálculo. |
|
|
|
|
La solución deberá permitir la generación de reportes para distintos niveles de usuarios: gerenciales, técnicos, etc. |
|
|
|
|
Capacidad para generar reportes del comportamiento histórico de una o varias variables |
|
|
|
|
REQUERIMIENTO PARA LA GESTIÓN DE DISPOSITIVOS DE RED |
|
|
|
|
Capacidad de monitoreo y almacenamiento de la configuración de dispositivos de comunicaciones (routers, switches, firewalls, UTMs, etc.) multi-proveedor (Cisco, Checkpoint, Sun, IBM, HP, DELL, Juniper, y las marcas más conocidas en el mercado boliviano) |
|
|
|
|
La captura de configuración de los dispositivos Deberá poder realizarse por lo menos mediante alguno de los siguientes protocolos de acceso TFTP, Telnet/FTP, SSH. |
|
|
|
|
Capacidad de monitoreo de configuraciones y generación de alarmas ante la detección de cambios. |
|
|
|
|
Capacidad de monitoreo de discrepancias en la configuración de running y startup, además de generación de alarmas. |
|
|
|
|
Capacidad de visualizar rápidamente y en pantalla los cambios realizados (líneas agregadas, líneas modificadas, líneas eliminadas), ante la detección de cambios en la configuración. |
|
|
|
|
Capacidad de creación de políticas de contenido de configuración que generen alarmas ante la detección de una configuración que no cumpla con la política. |
|
|
|
|
Capacidad para automatizar tareas de corrección de configuraciones (upload) ante la detección de un cambio no autorizado o el incumplimiento de una política. |
|
|
|
|
Capacidad para capturar configuraciones incluyendo dispositivos no certificados. |
|
|
|
|
Todas las funcionalidades requeridas para la gestión de configuración Deberán poder ser visualizadas y accedidas desde la misma interface de usuario. |
|
|
|
|
Capacidad para programar tareas de actualización o captura de configuraciones en masa (bulk tasks) en base a calendarios previamente definidos. |
|
|
|
|
Capacidad para generar reportes relacionados a los cambios de configuración detectados en un periodo determinado de tiempo y sobre un grupo definido de dispositivos. |
|
|
|
|
Capacidad para soportar procesos
de gestión de cambios implicando flujos de aprobaciones los
cuales pudieran implementarse en la misma solución o mediante la
integración con sistema xx xxxx de ayuda a implementarse a
futuro. |
|
|
|
|
Capacidad de recolectar información de flujo tipo Cisco NetFlow, S-flow y IPFIX desde múltiples dispositivos en forma simultánea a lo largo de toda la infraestructura de comunicaciones. |
|
|
|
|
La solución deberá mantener almacenada en su base de datos un mínimo histórico de información de 12 meses. Toda la información histórica almacenada en este repositorio deberá poder ser presentada con una ventana mínima de granularidad de 15 minutos. Los usuarios deberán poder seleccionar cualquier rango de 15 minutos sobre los últimos 12 meses almacenados mostrándose la información correspondiente a la utilización y protocolos para cada interface monitoreada. |
|
|
|
|
La solución propuesta deberá ser capaz de monitorear y generar reportes sobre un mínimo de 10000 protocolos por día y mostrar información de utilización para cada protocolo en forma individual. Esta característica Deberá estar disponible para cada una de las interfaces monitoreadas. |
|
|
|
|
El sistema deberá proveer funcionalidades que permitan la fácil ejecución de reportes sobre la información almacenada en su repositorio de largo plazo. La configuración y ejecución de los mismos Deberá estar asistida por interfaces gráficas que guíen a los usuarios. |
|
|
|
|
Capacidad de creación de reportes de forma tal que los usuarios puedan realizar búsquedas incluyendo todo el tráfico IP para un periodo histórico definido y de acuerdo a diferentes criterios y condiciones. El sistema deberá ser capaz de realizar búsquedas sobre todo el tráfico IP sin pérdidas o exclusiones de ningún tipo de tráfico. |
|
|
|
|
La solución propuesta deberá ser capaz de detectar en forma automática comportamientos anómalos o no autorizados en aplicaciones. |
|
|
|
|
Capacidad de agrupación de interfaces de acuerdo a diferentes criterios definidos por el usuario. Los usuarios podrán definir el nombre de los grupos y seleccionar las interfaces incluidas en cada grupo. El generador de reportes podrá ejecutar reportes en base a los grupos definidos. |
|
|
|
|
ESPECIFICACIONES PARA LA SOLUCIÓN DE ANÁLISIS DE REDES RETROSPECTIVO |
|
|
|
|
REQUERIMIENTOS GENERALES |
|
|
|
|
Capacidad para un rápido análisis de la causa raíz de los problemas actualmente en la producción que minimiza el tiempo de inactividad y el impacto en el usuario final. |
|
|
|
|
Capacidad de Identificación de forma precisa de qué usuarios, servicios y aplicaciones están consumiendo recursos de infraestructura (redes y servidores) así como ancho xx xxxxx. |
|
|
|
|
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura (redes y servidores). |
|
|
|
|
Capacidad de proveer información del consumo de los recursos de los servicios corporativos (para ayudar a tomar decisiones acerca de adquisiciones nuevas). |
|
|
|
|
Capacidad de análisis de tendencias de comportamiento de los servicios, su relación con elementos de infraestructura y nivel de cumplimiento de Niveles de Servicio (SLAs). |
|
|
|
|
Capacidad para capturar con precisión en las redes totalmente saturados; recoge full-duplex, estadísticas de captura de velocidad de cable; y puede monitorear múltiples enlaces Gigabit. |
|
|
|
|
REQUERIMIENTOS PARA GESTIÓN DE TOPOLOGÍAS Y FALLAS. |
|
|
|
|
Capacidad de captura exportacion de manera sencilla a los dispositivos de seguridad, el cumplimiento y herramientas forenses y otros analizadores de red. |
|
|
|
|
Capacidad para proporcionar análisis de transacciones de aplicaciones con gran detalle sobre de las capas de 5 a 7 del modelo OSI. |
|
|
|
|
Capacidad de incorporación de reglas de Snort o equivalentes para investigar las violaciones de seguridad y problemas de cumplimiento. |
|
|
|
|
Capacidad para proporcionar capacidades de resolución de problemas, con detalles sobre las comunicaciones de voz y vídeo, incluyendo jitter, pérdida de paquetes, y las métricas de puntuación como MOS / OMVs (en conjunto y sobre una base de conexión por conexión). |
|
|
|
|
Deberá contar con una interface gráfica para representar cualquier problemática detectada en los dispositivos dentro de los mapas topológicos destacando con un color el icono correspondiente al generador de la falla. |
|
|
|
|
La solución deberá poseer la capacidad de determinar el origen de la causa raíz de una falla sin que sea requerida la creación de reglas de correlación, programación ni personalización manual de ningún tipo. |
|
|
|
|
Como consecuencia del análisis de causa raíz se deberá generar una única alarma que indique y provea información sobre la falla detectada y su consecuente correlación de eventos. |
|
|
|
|
Las alarmas Deberán proveer información que les permita a los usuarios actuar en consecuencia para resolver el problema (Detección de la sintomatología del problema, causas probables, posibles acciones de reparación). |
|
|
|
|
Capacidad de análisis de impacto automático que permita valorar el impacto de una falla/alarma en términos de negocio en base a servicios de negocio, usuario o clientes afectados por la falla detectada. |
|
|
|
|
Capacidad de que el motor de análisis de causa raíz continúe en funcionamiento sin necesidad de ninguna intervención de configuración / re-configuración manual, ante cambios detectados en la topología |
|
|
|
|
Capacidad de proveer algoritmos para la correlación de eventos tanto dinámicos como configurables por los administradores (par de eventos, ráfaga de eventos, condicionales, etc.) para permitir la correlación de eventos que no tengan ninguna relación explicita entre ellos. |
|
|
|
|
Capacidad de generación de Mapas topológicos unificados en donde se pueda visualizar todos los componentes de la infraestructura incluyendo la plataforma virtual con diferenciación mediante íconos específicos para servidores físicos y servidores virtuales. |
|
|
|
|
Capacidad de correlación de eventos, análisis de causa raíz, aislamientos xx xxxxxx y análisis de impacto unificado para todas las tecnologías solicitadas (redes, servidores, base de datos y plataforma virtual). |
|
|
|
|
REQUERIMIENTO PARA GESTIÓN DE DESEMPEÑO Y CAPACIDAD |
|
|
|
|
La solución propuesta deberá concentrar y consolidar en un único repositorio toda la información relacionada a performance capturada de los diferentes componentes tecnológicos incluyendo redes, servidores (físicos y virtuales) y base de datos, etc. |
|
|
|
|
La solución propuesta deberá realizar Análisis de tendencias con base en la información histórica para Capacity Planning. |
|
|
|
|
La solución propuesta deberá permitir un control proactivo de indicadores clave de rendimiento (KPIs) |
|
|
|
|
La solución propuesta deberá ser capaz de determinar, por cada variable monitoreada, la tendencia de consumo de recursos, y posteriormente realizar un análisis que identifique potenciales problemas ordenándolos por prioridad. |
|
|
|
|
El sistema propuesto deberá ser capaz de calcular para cada muestra capturada el comportamiento normal (o baseline) de dicha variable para el dispositivo en cuestión sin requerir de programación ni personalización alguna. Posteriormente estos patrones normales deberán poder ser utilizados para la generación de alarmas y para tareas de Capacity Planning de los recursos (ej: ancho xx xxxxx IP de un enlace, cpu, memoria física, memoria virtual, paginación, discos, filesystems, etc.).. |
|
|
|
|
Capacidad de generar alertas en base a desviación del comportamiento o consumo normal de cada una de las variables monitoreadas para las diferentes tecnologías. |
|
|
|
|
Los reportes de la solución deberán ser personalizables y presentar la información acorde al rol del usuario. |
|
|
|
|
El tiempo de ventana del reporte deberá ser flexible y configurable, permitiendo reportes diarios, mensuales y anuales, y de valores máximos, mínimos y promedios. |
|
|
|
|
IV.- ESPECIFICACIONES PARA LA PLATAFORMA DE INTELIGENCIA OPERATIVA |
|
|
|
|
REQUERIMIENTOS GENERALES |
|
|
|
|
La solución propuesta deberá incluir un esquema de licenciamiento que permita instalar sus componentes de manera ilimitada y de acuerdo con las necesidades de la YPFB durante el periodo de implementación o posterior por así convenir a la Institución. |
|
|
|
|
La solución propuesta deberá permitir el crecimiento de manera lineal implementando componentes que permitan soportar el crecimiento en la cantidad de datos a analizar o bien en la cantidad de usuarios a consultar y visualizar los datos. |
|
|
|
|
REQUERIMIENTOS DE OPERACIÓN |
|
|
|
|
La solución propuesta deberá incluir mecanismos de tolerancia a fallas y balanceo de cargas incluido en la solución. Se requiere que los datos sean colectados sin perdida en los mismos. |
|
|
|
|
Capacidad de colectar eventos de los diferentes sistemas utilizando por lo menos los siguientes mecanismos: instalación de agente único de colección, recepción de eventos por syslog, recepción de eventos por SNMP, recepción de eventos del resultado de la ejecución de un programa (script), recepción de eventos de captura de tráfico de protocolos. |
|
|
|
|
La solución propuesta deberá ser capaz de entender cualquier evento generado por los sistemas de la dirección sin importar su origen, formato o fuente de información. |
|
|
|
|
La solución propuesta deberá ser capaz de indexar los eventos de modo que se puedan realizar búsquedas por palabras, códigos o frases contenidas en el evento. |
|
|
|
|
La solución propuesta deberá tener un lenguaje sencillo de utilizar para realizar las búsquedas, este lenguaje deberá permitir búsqueda por palabra, código o frases. |
|
|
|
|
La solución de centralización de eventos deberá poder ser ejecutada mínimo en las siguientes plataformas: Windows Vista, 7, 8 y 81. (32 y64 bits), Windows 2003, 2003 R2, 2008, 2008 R2, 2012 y 2012 R2 (32 y 64 bits), Linux kernel 2.6 o superior (32 y 64 bits), OSX 10.7 o superior (Intel) |
|
|
|
|
El agente de colección deberá ser compatible para las siguientes plataformas: Windows Vista, 7, 8 y 81. (32 y64 bits), Windows 2003, 2003 R2, 2008, 2008 R2, 2012 y 2012 R2 (32 y 64 bits), Linux kernel 2.6 o superior (32 y 64 bits), Solaris 10,11 (32 y 64 bits), OSX 10.7 o superior (Intel), FreeBSD 7,8 (32 y 64 bits), freeBDS 9 (64 bits), AIX 6.1 y 7.1, HP-UX11 v2 y v3 (PA-RISC e Itanium) |
|
|
|
|
Capacidad de soporte multi-tecnología, multi-proveedor. El motor de análisis de datos deberá ser capaz de identificar los diferentes eventos pertenecientes a dispositivos de comunicaciones e infraestructura por ejemplo: routers, switches, hubs, firewall, balanceadores, servidores, etc. |
|
|
|
|
La solución deberá incluir templates que permitan acelerar la adopción de la captura y entendimiento de los datos, de modo que se puedan crear vistas y reportes de una manera muy eficiente. |
|
|
|
|
La solución deberá incluir comandos de búsqueda que permitan procesar los datos de una manera ágil, estos comandos también Deberán permitir aplicar funciones estadísticas por campo para tener un mejor entendimiento de los problemas. Otros de los comandos que Deberá tener la solución son comandos predictivos. |
|
|
|
|
La solución propuesta deberá ser capaz xx xxxx eventos en archivos de texto, leer datos provenientes de puertos TCP o UDP. Deberá poder usar scripts para capturar información relevante así como conectarse a bases de datos a través de conexiones de tipo ODBC. La solución deberá poder exportar el resultado de las búsquedas utilizando ODBC hacia otras herramientas. |
|
|
|
|
|
|
|
|
|
La solución propuesta deberá tener la capacidad de integrarse con elementos de geo localización para representar eventos en mapas. |
|
|
|
|
La solución propuesta deberá contener APIS y mecanismos de integración con las aplicaciones desarrolladas por YPFB. |
|
|
|
|
REQUERIMIENTOS DE ALMACENAMIENTO |
|
|
|
|
La
solución propuesta deberá permitir la definición de políticas
de retención de datos en al menos tres capas: |
|
|
|
|
La solución propuesta deberá ser capaz de indexar datos en una tasa de al menos 20000 EPS (Eventos por segundo). |
|
|
|
|
La solución propuesta deberá indexar los datos a nivel de byte, de modo que se puedan aplicar búsquedas por código, palabra o frase. Deberá incluir mecanismos como reducción de mapas o similares que permitan que el análisis de los datos sea instantáneo. |
|
|
|
|
El agente de colección deberá ser capaz de entender eventos de aplicaciones desarrolladas por la dirección. En caso de requerir servicios de implementación para entender este tipo xx xxxxxxx Deberá incluirse el costo de este desarrollo. |
|
|
|
|
El agente de colección de datos Deberá ser capaz de capturar los datos sin importar la plataforma en la que está instalado, el formato de los mismos o su cantidad. Los datos Deberán ser enviados en su formato original y deberá incluir mecanismos de filtrado de datos, compresión y manejo de ancho xx xxxxx. |
|
|
|
|
Los eventos deberán ser almacenados en el servidor de la solución en su formato original, Deberá contar con mecanismos para validar la integridad de los eventos así como mecanismos que impidan el borrado de los eventos, se deberá permitir el borrado de los eventos solo por los usuarios autorizados. |
|
|
|
|
La solución propuesta deberá contar con mecanismos de auditoria que permitan identificar las actividades realizadas por los usuarios. |
|
|
|
|
La solución propuesta deberá contar con mecanismos para aplicar las políticas de retención, se requiere aplicar políticas para mantener eventos que faciliten el análisis de causa raíz, mantener en otra ubicación los eventos que faciliten el análisis histórico (al menos 9 meses) y una capa adicional que permita mantener múltiples años de almacenamiento en cinta o VTL |
|
|
|
|
La solución propuesta deberá ser capaz de integrarse con los mecanismos de respaldo actuales en YPFB. Se Deberá poder manejar respaldos históricos y diferenciales de los datos. |
|
|
|
|
REQUERIMIENTOS DE CONTROL DE ACCESO |
|
|
|
|
Capacidad de monitoreo a través
de una consola o interface web centralizada que incluya por lo
menos: |
|
|
|
|
La comunicación entre el agente y la solución de centralización de logs deberá permitir el control de ancho xx xxxxx y el manejo de tráfico cifrado. |
|
|
|
|
La solución propuesta deberá contener mecanismos de configuración de los agentes de colección de manera centralizada. |
|
|
|
|
La solución propuesta deberá contar con mecanismos de balanceo y alta disponibilidad integrados y no deberá requerir productos adicionales de otros fabricantes. |
|
|
|
|
Capacidad de proveer Tableros de Control donde se pueda analizar desde un solo punto en común (consola única) la calidad del servicio que se estén entregando en base a indicadores xx xxxxxx, disponibilidad, tiempos fuera de servicio, tiempos de reparación xx xxxxxx, rendimiento de servicios en el tiempo y análisis de tráfico de Red. |
|
|
|
|
Capacidad de análisis rápido de causa raíz de problemas en los servicios actualmente en producción y los que se instalarán en los próximos años (para reducir tiempos fuera de servicio). |
|
|
|
|
Capacidad de análisis histórico de comportamiento, para poder medir el impacto en los servicios por fallas en los recursos de infraestructura. |
|
|
|
|
V.- ESPECIFICACIONES ADICIONALES |
|
|
|
|
TIPO DE SOLUCIÓN |
|
|
|
|
La propuesta debe incluir la capacitación, instalación, configuración, programación (la customización, optimización) y puesta en marcha de la solución requerida, acorde a las especificaciones y necesidades de la red corporativa de YPFB, es decir la solución de la propuesta debe ser de tipo “Llave en mano”. |
|
|
|
|
MANTENIMIENTO |
|
|
|
|
El proveedor adjudicado debe realizar actualizaciones así como el mantenimiento de los componentes/módulos de la solución instalada, mientras dure el período de garantía en coordinación con la Dirección Nacional de Tecnologías de la Información y sin costo adicional. |
|
|
|
|
EXPERIENCIA DEL PROVEEDOR |
|
|
|
|
- El proveedor deberá contar con acreditación certificada por el fabricante de al menos cuatro (4) años de experiencia como proveedor de soluciones de Administración y Gestión de Rendimiento de Aplicaciones. Se debe adjuntar documentación respaldatoria. - El proveedor deberá demostrar haber realizado la implementación de 2 soluciones similares a la ofertada. Se aceptarán como documentación respaldatoria: fotocopias simples de contratos, facturas, certificados, órdenes de compra, de clientes a los que se les ha instalado la solución ofertada o equivalente. - El proveedor deberá demostrar con documentación (fotocopias simples) que cuenta con servicio técnico local autorizado en Bolivia, de la(s) marca(s) ofertada(s). |
|
|
|
|
EXPERIENCIA DEL PERSONAL TÉCNICO DEL PROVEEDOR |
|
|
|
|
El proveedor debe tener entre su personal de planta al menos tres (3) profesionales expertos y con certificación, emitida por el fabricante, en instalación, administración, gestión y solución de problemas de la solución ofertada. Se deben adjuntar las certificaciones de los profesionales. |
|
|
|
|
EXPERIENCIA DEL PROPONENTE EN IMPLEMENTACIONES |
|
|
|
|
El proveedor debe tener experiencia en la implementación de soluciones de Administración y gestión de aplicaciones de tipo empresarial. Se debe adjuntar documentación respaldatoria que podrá ser: fotocopias simples de contratos, facturas, certificados, órdenes de compra, de clientes a los que se les ha instalado la solución ofertada o equivalente. |
|
|
|
|
TRANSFERENCIA DE CONOCIMIENTOS |
|
|
|
|
Durante el período de implementación de la solución, el proveedor adjudicado realizará la transferencia de conocimientos mediante actividades que permitan al personal designado por la Dirección Nacional de Tecnologías de la Información administrar, mantener y soportar todas las funcionalidades de hardware y software del sistema implementado. |
|
|
|
|
MANUALES |
|
|
|
|
Se deben incluir al momento de la entrega manuales técnicos, de instalación, de usuario y documentos adicionales de las soluciones ofertadas en medio impreso y/o digital. |
|
|
|
|
INSPECCIÓN Y PRUEBAS |
|
|
|
|
El proveedor, de acuerdo a lo solicitado en puntos anteriores, debe establecer un calendario para realizar pruebas de programación (verificación en la configuración inicial, módulos, plantillas, etc.), adquisición de datos, monitoreo del sistema instalado coordinando con funcionarios de la DNTI. |
|
|
|
|
PLAZOS DE ENTREGA |
|
|
|
|
El tiempo de entrega de las
licencias será máximo de 15 días calendario a partir de la
firma del contrato. No se aceptaran entregas parciales. |
|
|
|
|
GARANTÍA TÉCNICA |
|
|
|
|
El proveedor adjudicado debe presentar una garantía de fábrica vigente por un periodo de tres (3) años a partir de la fecha de entrega de las soluciones ofertadas que debe incluir mano de obra, costos de atención en sitio donde se encuentre instalado el sistema, actualizaciones de versión de software. La modalidad de la garantía de fábrica debe ser 7x24. La garantía debe incluir soporte técnico remoto del fabricante mediante la apertura de casos en la web. |
|
|
|
|
LUGAR DE ENTREGA |
|
|
|
|
Las licencias solicitadas deberán ser entregadas en la Xxxxx xxxxx # 000, Xxxxxxxx xxxxxxx de YPFB para las respectivas pruebas. |
|
|
|
|
FORMA DE PAGO |
|
|
|
|
El pago se realizará a través del SIGMA, contra entrega total de los equipos, una vez que el comité de Recepción designado para el efecto, haya emitido el informe de conformidad, debiendo el proveedor emitir la factura correspondiente a nombre de YPFB con NIT 1020269020. (Manifestar Aceptación) |
|
|
|
|
VIGENCIA DEL CONTRATO |
|
|
|
|
El contrato establecido con la empresa proponente que se adjudique el proceso tendrá vigencia a partir del siguiente día hábil desde de la firma del mismo. (Manifestar Aceptación) |
|
|
|
|
MULTAS |
|
|
|
|
El PROVEEDOR se obligará a
cumplir con el plazo de entrega de los bienes, caso contrario
será multado con el 1 % sobre el importe total de la
adjudicación por día calendario de retraso. En caso de llegar
al veinte por ciento (20%) del monto total del contrato, el
contrato será resuelto quedando la adjudicación sin efecto, y
la empresa YPFB se reserva el derecho de realizar las gestiones
legales y administrativas que correspondan. |
|
|
|
|
ANTICIPO |
|
|
|
|
En el presente proceso de contratación no se otorgará Anticipo. (Manifestar Aceptación) |
|
|
|
|
(Firma del proponente)
(Nombre completo del proponente)