Esta sección constituye el detalle de los bienes y/o servicios con sus respectivas especificaciones técnicas - EETT, de manera clara y precisa para que el oferente elabore su oferta. Salvo aquellas EETT de productos ya determinados por plantillas aprobadas por la DNCP.

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

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

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

• Identificar el nombre, cargo y la dependencia de la Institución de quién solicita el llamado a ser publicado:

Nombre: Javier Espínola
Cargo: Director
Dependencia: Dirección de Tecnología de la Información

• Necesidad que se pretende satisfacer mediante la contratación a ser realizada:

Este Sistema requiere que tenga actualización permanente para la resolución de cualquier inconveniente que pueda surgir en los módulos de Sistema, actualizaciones de los componentes del Sistema es esencial por si se presente cambios de reglamentaciones que afecten el funcionamiento del mismo, en cuanto al desarrollo de personalizaciones se prevé para la integración total de los módulos con los sistemas actuales de PETROPAR.

• Planificación. (si se trata de un llamado periódico o sucesivo, o si el mismo responde a una necesidad temporal):

La presente contratación responde a una necesidad periódica debido a que es necesario contar con las actualizaciones y desarrollos personalizados del Sistema de Gestión de Recursos Humanos y la integración total de los Sistemas de Petropar.

•  Justificar la planificación (si se trata de un llamado periódico o sucesivo, o si el mismo responde a una necesidad temporal):

La presente contratación responde a una necesidad periódica debido a que es necesario contar con las actualizaciones y desarrollos personalizados del Sistema de Gestión de Recursos Humanos y la integración total de los Sistemas de Petropar.

• Justificar las especificaciones técnicas establecidas:

Las especificaciones técnicas se elaboran en función a las necesidades de Petropar.

Los productos y/o servicios a ser requeridos cuentan con las siguientes especificaciones técnicas:

El propósito de la Especificaciones Técnicas (EETT), es el de definir las características técnicas de los bienes que la convocante requiere. La convocante preparará las EETT detalladas teniendo en cuenta que:

-      Las EETT sirven de referencia para verificar el cumplimiento técnico de las ofertas y posteriormente evaluarlas. Por lo tanto, unas EETT bien definidas facilitarán a los oferentes la preparación de ofertas que se ajusten a los documentos de licitación, y a la convocante el examen, evaluación y comparación de las ofertas.

-      En las EETT se deberá estipular que todos los bienes o materiales que se incorporen en los bienes deberán ser nuevos, sin uso y del modelo más reciente o actual, y que contendrán todos los perfeccionamientos recientes en materia de diseño y materiales, a menos que en el contrato se disponga otra cosa.

-      En las EETT se utilizarán las mejores prácticas. Ejemplos de especificaciones de adquisiciones similares satisfactorias en el mismo sector podrán proporcionar bases concretas para redactar las EETT.

-      Las EETT deberán ser lo suficientemente amplias para evitar restricciones relativas a manufactura, materiales, y equipo generalmente utilizados en la fabricación de bienes similares.

-      Las normas de calidad del equipo, materiales y manufactura especificadas en los Documentos de Licitación no deberán ser restrictivas. Se deberán evitar referencias a marcas, números de catálogos u otros detalles que limiten los materiales o artículos a un fabricante en particular. Cuando sean inevitables dichas descripciones, siempre deberá estar seguida de expresiones tales como “o sustancialmente equivalente” u “o por lo menos equivalente”, remitiendo la aclaración respectiva.  Cuando en las ET se haga referencia a otras normas o códigos de práctica particulares, éstos solo serán aceptables si a continuación de los mismos se agrega un enunciado indicando otras normas emitidas por autoridades reconocidas que aseguren que la calidad sea por lo menos sustancialmente igual.

-      Asimismo, respecto de los tipos conocidos de materiales, artefactos o equipos, cuando únicamente puedan ser caracterizados total o parcialmente mediante nomenclatura, simbología, signos distintivos no universales o marcas, únicamente se hará a manera de referencia, procurando que la alusión se adecue a estándares internacionales comúnmente aceptados.

-      Las EETT   deberán describir detalladamente los siguientes requisitos con respecto a por lo menos lo siguiente:

(a)      Normas de calidad de los materiales y manufactura para la producción y fabricación de los bienes.

(b)      Lista detallada de las pruebas requeridas (tipo y número).

(c)       Otro trabajo adicional y/o servicios requeridos para lograr la entrega o el cumplimiento total.

(d)      Actividades detalladas que deberá cumplir el proveedor, y consiguiente participación de la convocante.

(e)      Lista detallada de avales de funcionamiento cubiertas por la garantía, y las especificaciones de las multas aplicables en caso de que dichos avales no se cumplan.

-              Las EETT deberán especificar todas las características y requisitos técnicos esenciales y de funcionamiento, incluyendo los valores máximos o mínimos aceptables o garantizados, según corresponda.  Cuando sea necesario, la convocante deberá incluir un formulario específico adicional de oferta (como un Anexo a la de Oferta), donde el oferente proporcionará la información detallada de dichas características técnicas o de funcionamiento con relación a los valores aceptables o garantizados.

Cuando la convocante requiera que el oferente proporcione en su oferta datos sobre una parte de o todas las Especificaciones Técnicas, cronogramas técnicos, u otra información técnica, la convocante deberá detallar la información requerida y la forma en que deberá ser presentada por el oferente en su oferta.

Si se debe proporcionar un resumen de las EETT, la convocante deberá insertar la información en la tabla siguiente. El oferente preparará un cuadro similar para documentar el cumplimiento con los requerimientos.

ACTUALIZACIÓN ESTANDAR DEL SISTEMA DE RECURSOS HUMANOS

Ítem 1 - Soporte estándar del sistema de RRHH                        

Consideraciones Generales

El objetivo de este Ítem es contar con los Soportes del sistema de gestión de Recursos Humanos de Petropar. Con el fin de garantizar el correcto funcionamiento de los módulos implementados para la gestión de talento humano.

Para el ítem del llamado, los Soportes serán solicitados por medio de órdenes de suministros emitido por el administrador del contrato a solicitud del área de Recursos Humanos y/o la Dirección de Tecnología.

El oferente deberá informar sobre los trabajos de Soporte del Sistema solicitados a través de la Orden de suministro

El Soporte deberá ser realizada por los técnicos de la empresa oferente en el horario laboral de lunes a viernes de manera presencial y/o  remoto en caso de urgencia o fines de semana según la necesidad. 

El Soporte remota podrá efectuarse con acceso remoto vía internet, en este último caso la empresa podrá solicitar el acceso al servidor al área de DTI además de contar con la autorización de la Dirección de Recursos Humanos y/o responsable designado.

Una vez finalizado cada Soporte se cerrará la sesión de acceso a internet. Igualmente se podrá utilizar otro tipo de comunicación de modo a solucionar el problema existente, siempre y cuando no transgreda lo estipulado en la Política de Seguridad de la institución.

Las mejoras, ajustes y modificaciones realizadas en el sistema deben impactar en todos los informes, la empresa será la encargada de realizar está verificación e implementación.

Los Soportes al sistema se deberán realizar fuera del horario laboral, salvo excepciones previa coordinación entre las partes. Requerimientos Técnicos:

Durante la vigencia del contrato, se harán Soportes requeridos a las versiones, reportes y funciones estándar

La Asistencia presencial incluyen:

Soporte General. Acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuración del código, definición más clara del sistema y optimización del rendimiento y eficiencia. Incluye mantenimiento de ambientes de calidad y de backup del sistema.

Soporte Adaptativo. Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos y comunicaciones.

Soporte Correctivo. Aquellos cambios precisos para corregir, por errores del producto software, los problemas que no puedan ser solucionados por el personal de la institución, en cuyo caso la institución generará los pedidos de Soporte para cada evento en particular.

Realizar diagnóstico y solución de los problemas que afecten a los productos se asistirá a la institución en la apertura de casos de soporte con el fabricante de bases de datos y herramientas utilizadas en los sistemas.

Revisión de bitácoras del sistema operativo, bases de datos y aplicativos para detectar situaciones anómalas que podrían ocasionar caídas en el sistema: La revisión de los componentes de software se realiza considerando las mejores prácticas y configuraciones inherentes a las aplicaciones y sus copias de seguridad.

1. Listado de Tecnologías:

Incluir un detalle técnico de las tecnologías, lenguajes y plataformas en las que está desarrollado el sistema de RRHH.

Aplicaciones Web

1. Base de datos: Se deberá utilizar SQL Server 2022 (versión 16.0), compatible con entornos multiplataforma, tanto de tipo Open Source como propietario, incluyendo: Red Hat Enterprise Linux 64 bits (o superior), Debian Linux Server 64 bits (o superior), Windows Server 64 bits.
2. Web tipo RIA (Rich Internet Application): Aplicación web con características de múltiples páginas integradas en una interfaz unificada, que combina funciones client-side y server-side, utilizando renderización tanto del lado del cliente como del servidor para optimizar el rendimiento y la seguridad. La aplicación debe permitir a los usuarios interactuar con la plataforma de forma ágil e intuitiva. Para este fin, deberá utilizarse AJAX en conjunto con la librería Ext JS versión 7.8 o superior.
3. La sesión debe gestionarse del lado del servidor, el cual será responsable de renderizar la interfaz de usuario (UI) y enviar al cliente únicamente el HTML resultante. Este enfoque debe ayudar a mejorar la seguridad al minimizar el riesgo de ingeniería inversa en el lado del cliente. Adicionalmente debe soportar la creación de scripts de eventos JavaScript del lado del cliente, pero esto solo deberá ser utilizado para refrescar datos o funciones que no impliquen fallas o agujeros de seguridad. La visualización deberá ser exactamente igual en cualquiera de los siguientes navegadores (en sus últimas versiones): IE 9+, Microsoft Edge, FireFox, Chrome, Safari y Opera.
4. Compatibilidad nativa de 64 bits. Todas las aplicaciones deberán ser construidas y publicadas para ejecutarse de forma nativa en arquitecturas de 64 bits, aprovechando así toda la capacidad de hardware disponible en los servidores.
5. Formato binario optimizado: En todos los casos, tanto las aplicaciones como sus componentes deberán distribuirse en formato binario. No se deberá hacer uso de lenguajes interpretados, capas intermedias de abstracción u otros mecanismos que puedan afectar negativamente el rendimiento del sistema.
6. El despliegue final deberá poder realizarse en modo standalone (como servicios independientes), como servicio de Windows, o mediante servidores de aplicaciones, ya sea IIS 10 utilizando un módulo ISAPI, o Apache 2 mediante un módulo nativo.
7. Soporte para monitoreo de bases de datos. Se deberá proveer una herramienta de monitoreo de base de datos integrada. Esta herramienta deberá permitir el seguimiento de operaciones INSERT, UPDATE y DELETE realizadas por el sistema, incluyendo la medición de tiempos de ejecución para detectar posibles cuellos de botella en el rendimiento.
8. Soporte y provisión de herramientas de Stress. Se deberá proporcionar una herramienta de pruebas de estrés (stress testing), diseñada para simular condiciones extremas de uso en el sistema o aplicación, con el objetivo de evaluar su rendimiento y estabilidad bajo cargas intensas o alto tráfico. Estas pruebas permitirán identificar cuellos de botella, vulnerabilidades y puntos críticos que podrían provocar fallos o interrupciones en un entorno real. El sistema provisto deberá permitir una integración nativa con esta herramienta mediante una configuración predefinida.
9. Los despliegues de aplicaciones deberán ser escalables, mediante una herramienta que permita desplegar múltiples instancias de una misma aplicación, con el fin de sectorizar y distribuir la carga del sistema.
10. Las aplicaciones deberán permitir la interconexión entre instancias para formar nodos, gestionando automáticamente las sesiones. El sistema deberá ser capaz de instanciar nuevos nodos según la demanda de sesiones, y eliminar las sesiones inactivas de forma automática.
11. Despliegue en caliente. El sistema deberá permitir la actualización de aplicaciones sin requerir el reinicio de servidores ni la interrupción del servicio, minimizando así los tiempos de inactividad.
12. Despliegue remoto. Se deberá contar con una funcionalidad que permita cargar nuevas versiones de ejecutables a través de una interfaz gráfica. A medida que las sesiones activas sean liberadas, dichas versiones deberán reemplazar automáticamente a las anteriores, sin necesidad de intervención manual.
13. Identificación de sistemas y componentes: Todos los componentes del sistema deberán estar identificados por su nombre y versión, utilizando el esquema: Número de Versión + Número de Revisión + Número de Build (por ejemplo, 2.15.24). Esta nomenclatura permitirá a los usuarios consultar de forma unívoca las funcionalidades disponibles en cada versión, facilitando la gestión por parte de los administradores del sistema.
14. Despliegue en clúster.  El sistema deberá soportar de forma nativa el despliegue en clúster, permitiendo definir, desde su propia configuración, un servidor maestro y múltiples servidores esclavos. Estos nodos deberán operar como una única instancia lógica, distribuyendo la carga de trabajo de manera eficiente. El sistema deberá permitir el despliegue de nuevas versiones o actualizaciones en caliente, sin necesidad de detener servicios ni reiniciar nodos.

Aplicaciones móviles

1. Base de datos: Se deberá utilizar SQL Server 2022 (versión 16.0), compatible con entornos multiplataforma, tanto de tipo Open Source como propietario, incluyendo: Red Hat Enterprise Linux 64 bits (o superior), Debian Linux Server 64 bits (o superior), Windows Server 64 bits.
2. Servidor de aplicaciones. Servidor basado en arquitectura REST/JSON.
   1. Formatos de peticiones configurables. El sistema deberá ofrecer dos formatos de solicitud configurables por el administrador:

• Un formato basado en JSON, donde los datos intercambiados entre las aplicaciones móviles y el servidor se representarán como texto estructurado.
• Un formato binario, que no será legible en texto plano, pero ofrecerá un mayor rendimiento.
  El administrador podrá definir dinámicamente factores como la cantidad de terminales, volumen de consultas u otros criterios de uso.
  2. Autenticación robusta mediante JWT. La autenticación deberá implementarse mediante JWT (JSON Web Token). La aplicación móvil se autenticará y obtendrá un token luego de la validación por parte del servidor de aplicaciones. Cada recurso, servicio o método remoto estará accesible únicamente si la solicitud contiene un token válido en la cabecera HTTP.
  3. Uso de métodos HTTP estándar. El sistema deberá utilizar los métodos HTTP estándar POST, GET, PUT, DELETE, y permitir actualizaciones parciales de objetos a través del método PATCH.
  4. Documentación de API. Se deberá proveer documentación técnica de los endpoints disponibles utilizando herramientas como Swagger y/o ReDoc.
  5. Almacenamiento en caché y cola de solicitudes en modo kernel. El sistema debe contar con mecanismos de cacheo y encolado de solicitudes a nivel de kernel, lo que reduce la sobrecarga por cambio de contexto. Deberá permitir que múltiples aplicaciones o procesos compartan el mismo puerto (en diferentes direcciones IP o bindings).
  6. Múltiples engines de servicio. El sistema deberá soportar diversos engines para el manejo de peticiones HTTP, incluyendo:

• HTTP.sys-based Server, que opera a nivel del kernel con alta eficiencia en conexiones concurrentes.
• Módulo nativo de Apache 2, para entornos basados en servidores web.
• Adicionalmente, deberá ofrecer un modo standalone para pruebas o entornos de despliegue interno.
  7. Compresión de datos. La transmisión de datos deberá contar con compresión nativa, para mejorar el uso del ancho de banda y reducir los tiempos de respuesta.
  8. Encriptación en la transmisión. Deberá soportarse la encriptación de datos en tránsito de forma nativa, garantizando la confidencialidad de la información entre el cliente y el servidor.
  9. Soporte CORS (Cross-Origin Resource Sharing). El sistema deberá implementar políticas CORS que permitan compartir recursos entre orígenes cruzados de forma controlada y segura.
  10. Middleware de Forward para entornos con proxy inverso. El sistema deberá incluir soporte para middleware de forward headers, permitiendo su correcta operación cuando se encuentra detrás de proxys inversos o balanceadores de carga como Nginx, Traefik o HAProxy.
  11. Logging de eventos. Deberá ofrecer un sistema integrado de registro de eventos, que permita auditar las peticiones provenientes de dispositivos móviles. El sistema deberá registrar en formato texto plano por defecto, pero también ofrecer manejadores opcionales para consola, HTML, CSV, servicios TCP/IP o el Registro de eventos de Windows.
  12. Compatibilidad nativa de 64 bits. Todas las aplicaciones deberán estar construidas y publicadas para ejecutarse de forma nativa en entornos de 64 bits, aprovechando completamente los recursos del hardware disponible en los servidores.
  13. Distribución en formato binario optimizado. Tanto las aplicaciones como sus componentes deberán distribuirse en formato binario, evitando el uso de lenguajes interpretados, capas de abstracción innecesarias u otros mecanismos que puedan comprometer el rendimiento.
  14. Panel de control para administración. El sistema deberá incluir un panel de control visual (GUI) que permita realizar configuraciones y tareas administrativas de forma centralizada y amigable.

3. Aplicación para teléfonos móviles.
   1. Las aplicaciones para dispositivos móviles deberán ser nativas y compiladas en formato binario, garantizando el mejor rendimiento posible según las características del hardware.

Android:

• La aplicación deberá ser compatible con la versión estable actual, Android 16 (API 36).
• Deberá compilarse para procesadores ARM de 32 y 64 bits, soportando los ABIs armeabi-v7a (para compatibilidad con dispositivos más antiguos) y arm64-v8a (requerido para publicación en tiendas oficiales).
• Se deberá generar un Android App Bundle (AAB) que incluya binarios tanto de 32 como de 64 bits, con todas las firmas digitales definidas por la institución para su distribución en las tiendas de aplicaciones.

iOS:

• La aplicación deberá ser compatible con la última versión disponible, iOS 18.5.
• Deberá ser una aplicación nativa compilada para la arquitectura ARM64, correspondiente a los procesadores A-Series de Apple.
• La compilación deberá realizarse usando Xcode en la versión indicada por Apple, conforme a las guías oficiales de publicación en la App Store.
• Se deberán seguir los estándares de diseño y usabilidad HIG (Human Interface Guidelines) establecidos por Apple para minimizar rechazos durante el proceso de revisión.

Además, se deberá proveer todo el material gráfico necesario para la publicación en las tiendas, incluyendo artes, capturas de pantalla y otros elementos visuales. Estos deberán cumplir con las especificaciones técnicas de calidad, resolución (DPI), tamaño y formatos definidos por cada tienda.

2. Indicadores de Cumplimiento del SLA (Acuerdo de Nivel de Servicio):

Clasificación por niveles de severidad de los incidentes.

Establecer tiempos de respuesta y resolución esperados.

Incluir indicadores técnicos para verificar el cumplimiento durante la ejecución del contrato.

4. Forma de prestación del servicio.
   1. Petropar será responsable de realizar los pedidos de servicio cuando considere que existe un fallo o malfuncionamiento correspondiente a cualquier módulo del sistema mencionado más arriba. El servicio de soporte técnico será prestado a solicitud de la Unidad de Recursos Humanos o responsable designado por escrito vía correo electrónico.
   2. Todas las tareas realizadas deberán efectuarse en forma conjunta con el personal designado por Petropar de manera a asegurar la adecuada transferencia de conocimientos hacia el personal de Petropar.
   3. Soporte correctivo, remoto en caso de urgencia, de 07:00 a 17:00 horas, de lunes a viernes con técnicos de la oferente. El soporte remoto podrá efectuarse internet, en este caso la oferente solicitará el acceso al servidor de TI, además de contar con la autorización de la Unidad de Recursos Humanos y/o Responsable designado.

Una vez finalizado cada servicio se cerrará la sesión de acceso. Igualmente se podrá utilizar otro tipo de comunicación de modo a solucionar el problema existente, siempre y cuando no transgreda lo estipulado en la Política de Seguridad de Petropar.

1. 4. Petropar notificará las anomalías que se presenten incluyendo la siguiente información:
      1. Fecha y hora.
      2. Descripción del problema.
      3. Usuarios y procesos afectados.
      4. Nivel de criticidad de la falla.
   5. la oferente mantendrá un registro de los mismos, utilizando un sistema de seguimiento de tareas, que asignará automáticamente un número de incidencia y a su vez deberá estar integrada al sistema de control de versiones, que permita conocer la revisión en la cual se ha solucionado el incidente.
   6. Las resoluciones a los problemas que pudiesen surgir se ajustarán a lo establecido en la Tabla Plazos de Resolución de Incidentes. Para el caso que la resolución del problema sea imposible de resolver en los plazos estipulados, la oferente acordará con Petropar un nuevo plazo.

• • El oferente acompañará a los técnicos de Petropar en la continua implementación de tareas, aportando la     experiencia de implementaciones anteriores.
  • A la finalización de cada servicio de soporte técnico La Oferente elaborará una hoja de soporte. En caso de soporte  remoto será documentado el servicio técnico a través del email.
  • A petición de Petropar se emitirá un informe de los servicios técnicos prestados, consignando en el mismo las fechas de realización del soporte, tareas realizadas y funcionario firmante.

Se contempla la asistencia presencial fija para cada liquidación de salarios dentro del mes, en fechas y horarios a definir conjuntamente

3. Entregables del Soporte Técnico:

Incorporar explícitamente una lista de entregables documentales, tales como:

Informes de atención técnica.

Registro de incidentes resueltos.

Recomendaciones de mejora aplicadas.

Reportes periódicos de desempeño del servicio.

4. Duración del Servicio:

Especificar el plazo de duración del servicio de soporte.

18 (dieciocho) meses.

Entregables

En procedimientos de Menor Cuantía, la aplicación de la preferencia reservada a las MIPYMES prevista en el artículo 34 inc b) de la Ley N° 7021/22 ‘’De Suministro y Contrataciones Públicas" será de conformidad con las disposiciones que se emitan para el efecto. Son consideradas Mipymes las unidades económicas que, según la dimensión en que organicen el trabajo y el capital, se encuentren dentro de las categorías establecidas en el Artículo 4° de la Ley N° 7444/25 QUE MODIFICA LA LEY Nº 4457/2012 ‘’PARA LAS MICRO, PEQUEÑAS Y MEDIANAS EMPRESAS’’, y se ocupen del trabajo artesanal, industrial, agroindustrial, agropecuario, forestal, comercial o de servicio.

No aplica

No aplica

No aplica

No aplica