¿Se considerará como cumplimiento suficiente de los puntos de seguridad que la solución se despliegue en una nube certificada (ISO 27001, SOC2, etc.) y que el fabricante acredite dichas certificaciones, junto con los controles nativos de la plataforma?
¿Se considerará como cumplimiento suficiente de los puntos de seguridad que la solución se despliegue en una nube certificada (ISO 27001, SOC2, etc.) y que el fabricante acredite dichas certificaciones, junto con los controles nativos de la plataforma?
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
La solución deberá ser implementada bajo un esquema on-premise sin admitir otro tipo de solución alternativa.
122
Proveedor actual y continuidad tecnológica
A efectos de comprender mejor el contexto de este proyecto, ¿podrían indicar qué plataforma WFMS utiliza actualmente ANDE y quién es el proveedor responsable de su implementación y soporte?
b) ¿Este llamado tiene como objetivo reemplazar esa plataforma actual, ampliarla o formalizar su continuidad?
A efectos de comprender mejor el contexto de este proyecto, ¿podrían indicar qué plataforma WFMS utiliza actualmente ANDE y quién es el proveedor responsable de su implementación y soporte?
b) ¿Este llamado tiene como objetivo reemplazar esa plataforma actual, ampliarla o formalizar su continuidad?
Al respecto, sírvanse considerar para la elaboración de sus ofertas, que el presente llamado tiene como objetivo la "Adquisición y Puesta en Servicio del Work Force Management System - WFMS", software de gestión de cuadrillas de campo e inventario, a ser implementada e integrada con distintos sistemas funcionales de la Convocante, conforme lo establecido en el Pliego de Bases y Condiciones y supeditada a las Especificaciones Técnicas requeridas.
123
Proveedor actual y continuidad tecnológica
¿Puede ANDE confirmar que el presente pliego no está condicionado a la continuidad del proveedor actual y que existe una apertura real a evaluar soluciones de otros fabricantes, siempre que cumplan los requisitos funcionales y de integración, a fin de garantizar condiciones de competencia transparentes?
¿Puede ANDE confirmar que el presente pliego no está condicionado a la continuidad del proveedor actual y que existe una apertura real a evaluar soluciones de otros fabricantes, siempre que cumplan los requisitos funcionales y de integración, a fin de garantizar condiciones de competencia transparentes?
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo indicado en el Pliego de Bases y Condiciones y sus Adendas N° 1, 2 y 3.
124
Mecanismos de evaluación comparativa (PoC / demostraciones)
¿ANDE considera la posibilidad de incluir, dentro del procedimiento de evaluación, demostraciones prácticas o pruebas de concepto con escenarios concretos (OT comerciales, fraudes, integración con CIS/GIS), que permitan comparar de forma objetiva el desempeño de distintas soluciones?
16-02-2026
18-05-2026
Mecanismos de evaluación comparativa (PoC / demostraciones)
¿ANDE considera la posibilidad de incluir, dentro del procedimiento de evaluación, demostraciones prácticas o pruebas de concepto con escenarios concretos (OT comerciales, fraudes, integración con CIS/GIS), que permitan comparar de forma objetiva el desempeño de distintas soluciones?
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo indicado en el Pliego de Bases y Condiciones y sus Adendas N° 1, 2 y 3.
125
1) Normas de interoperabilidad (CIM IEC 61968 / MultiSpeak) sin perfiles ni equivalencias
Hecho/Observación. El PBC/EETT exige CIM IEC 61968/MultiSpeak en varios puntos, pero no precisa perfiles ni si admite equivalentes (APIs REST OpenAPI 3.0, middleware/ESB), ni define si el cumplimiento debe ser nativo en el WFMS o puede implementarse vía capa de integración.
Fundamento técnico‑jurídico. La Ley 7021/22 impone neutralidad tecnológica, claridad y proporcionalidad. Exigir un estándar sin perfiles ni admitir equivalencias válidas restringe la concurrencia y puede favorecer soluciones preexistentes.
Petitorio.
• Precisar perfiles/domínios CIM y casos de uso obligatorios;
• Admitir equivalencias por capa de integración (ESB/API Gateway/iPaaS) y APIs REST OpenAPI 3.0;
• Incorporar PoC/homologación con escenarios e indicadores objetivos.
20-02-2026
18-05-2026
1) Normas de interoperabilidad (CIM IEC 61968 / MultiSpeak) sin perfiles ni equivalencias
Hecho/Observación. El PBC/EETT exige CIM IEC 61968/MultiSpeak en varios puntos, pero no precisa perfiles ni si admite equivalentes (APIs REST OpenAPI 3.0, middleware/ESB), ni define si el cumplimiento debe ser nativo en el WFMS o puede implementarse vía capa de integración.
Fundamento técnico‑jurídico. La Ley 7021/22 impone neutralidad tecnológica, claridad y proporcionalidad. Exigir un estándar sin perfiles ni admitir equivalencias válidas restringe la concurrencia y puede favorecer soluciones preexistentes.
Petitorio.
• Precisar perfiles/domínios CIM y casos de uso obligatorios;
• Admitir equivalencias por capa de integración (ESB/API Gateway/iPaaS) y APIs REST OpenAPI 3.0;
• Incorporar PoC/homologación con escenarios e indicadores objetivos.
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
126
2) Licencias ‘perpetuas’ y discrepancia 380 vs 500 usuarios
Hecho/Observación. El PBC menciona 500 usuarios activos y, en otra sección, 380 licencias perpetuas. Además, se impone perpetuidad cuando el mercado WFMS/Field Service opera mayormente con suscripciones/SaaS.
Fundamento técnico‑jurídico. La inconsistencia afecta comparabilidad; imponer perpetuo desincentiva competencia y eficiencia. Corresponde privilegiar neutralidad de modelos de provisión (perpetuo/suscripción) mientras se cumplan SLA y soberanía de datos.
Petitorio.
• Unificar y aclarar el total de usuarios y su matriz (móviles/back‑office/terceros);
• Aceptar suscripción (on‑prem/híbrida/cloud privada/SaaS) con SLA ≥ 99,5 % y soberanía de datos en igualdad con perpetuo.
20-02-2026
18-05-2026
2) Licencias ‘perpetuas’ y discrepancia 380 vs 500 usuarios
Hecho/Observación. El PBC menciona 500 usuarios activos y, en otra sección, 380 licencias perpetuas. Además, se impone perpetuidad cuando el mercado WFMS/Field Service opera mayormente con suscripciones/SaaS.
Fundamento técnico‑jurídico. La inconsistencia afecta comparabilidad; imponer perpetuo desincentiva competencia y eficiencia. Corresponde privilegiar neutralidad de modelos de provisión (perpetuo/suscripción) mientras se cumplan SLA y soberanía de datos.
Petitorio.
• Unificar y aclarar el total de usuarios y su matriz (móviles/back‑office/terceros);
• Aceptar suscripción (on‑prem/híbrida/cloud privada/SaaS) con SLA ≥ 99,5 % y soberanía de datos en igualdad con perpetuo.
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
127
3) Arquitectura prescriptiva on‑prem y diagramas ‘obligatorios’
Hecho/Observación. Los diagramas incluidos parecen orientar a on‑prem y podrían excluir arquitecturas SaaS/cloud equivalentes.
Fundamento técnico‑jurídico. Imponer hosting on‑prem sin justificación técnica limita la concurrencia y eleva CAPEX. La 7021/22 exige especificaciones objetivas y no restrictivas.
Petitorio.
• Declarar los diagramas como referenciales;
• Admitir on‑prem/híbrida/cloud privada/SaaS con cumplimiento de seguridad (ISO 27001/SOC 2), SLA 99,5 % y soberanía de datos.
20-02-2026
18-05-2026
3) Arquitectura prescriptiva on‑prem y diagramas ‘obligatorios’
Hecho/Observación. Los diagramas incluidos parecen orientar a on‑prem y podrían excluir arquitecturas SaaS/cloud equivalentes.
Fundamento técnico‑jurídico. Imponer hosting on‑prem sin justificación técnica limita la concurrencia y eleva CAPEX. La 7021/22 exige especificaciones objetivas y no restrictivas.
Petitorio.
• Declarar los diagramas como referenciales;
• Admitir on‑prem/híbrida/cloud privada/SaaS con cumplimiento de seguridad (ISO 27001/SOC 2), SLA 99,5 % y soberanía de datos.
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
Las arquitecturas publicadas son de referencia correspondiéndose imperativamente a una solución tipo on-premise, sin admitir otro tipo de solución alternativa.
128
4) Experiencia local (referencias en Paraguay) y montos acumulados restrictivos
Hecho/Observación. Se exigen referencias en Paraguay y montos acumulados (60 % total y 40 % individual) poco realistas para WFMS a la escala requerida, lo que favorece incumbencia y reduce competencia.
Fundamento técnico‑jurídico. La experiencia debe valorarse por equivalencia funcional y complejidad (utilities/OT, AMI/MDM, GIS/ERP, movilidad, inventarios), no por ubicación geográfica, para cumplir neutralidad e igualdad.
Petitorio.
• Sustituir referencias locales por referencias internacionales comparables en utilities;
• Permitir acumulación modular (proyectos distintos que cubran los módulos) y partnerships con fabricante/integrador.
20-02-2026
18-05-2026
4) Experiencia local (referencias en Paraguay) y montos acumulados restrictivos
Hecho/Observación. Se exigen referencias en Paraguay y montos acumulados (60 % total y 40 % individual) poco realistas para WFMS a la escala requerida, lo que favorece incumbencia y reduce competencia.
Fundamento técnico‑jurídico. La experiencia debe valorarse por equivalencia funcional y complejidad (utilities/OT, AMI/MDM, GIS/ERP, movilidad, inventarios), no por ubicación geográfica, para cumplir neutralidad e igualdad.
Petitorio.
• Sustituir referencias locales por referencias internacionales comparables en utilities;
• Permitir acumulación modular (proyectos distintos que cubran los módulos) y partnerships con fabricante/integrador.
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
129
6) Soporte ‘evolutivo’ abierto durante toda la vigencia
Hecho/Observación. El PBC indica ajustes y nuevas funcionalidades durante toda la vigencia, sin límite ni proceso de cambio, trasladando riesgos no cuantificables.
Fundamento técnico‑jurídico. Debe acotarse a parametrizaciones post go‑live y encauzar evoluciones mayores por gestión de cambios (alcance/plazo/costo), para preservar equidad y valor por dinero.
Petitorio.
• Limitar a ajustes menores dentro de 3 meses post salida en vivo;
• Canalizar nuevas funcionalidades por gestión formal de cambios y contratación específica.
20-02-2026
18-05-2026
6) Soporte ‘evolutivo’ abierto durante toda la vigencia
Hecho/Observación. El PBC indica ajustes y nuevas funcionalidades durante toda la vigencia, sin límite ni proceso de cambio, trasladando riesgos no cuantificables.
Fundamento técnico‑jurídico. Debe acotarse a parametrizaciones post go‑live y encauzar evoluciones mayores por gestión de cambios (alcance/plazo/costo), para preservar equidad y valor por dinero.
Petitorio.
• Limitar a ajustes menores dentro de 3 meses post salida en vivo;
• Canalizar nuevas funcionalidades por gestión formal de cambios y contratación específica.
Al respecto, sírvanse considerar para la elaboración de sus ofertas, lo establecido en la Adenda N° 2, publicada en el Portal de la DNCP.
130
5) Volumetría, datos maestros y alcance de integraciones no definidos
Hecho/Observación. No se publican volumetrías (OT/mes por sistema), catálogos/IDs homologados, criterios de georreferenciación, ambientes (DEV/QA/PROD), ni detalle del 99,5 % (componentes, medición, exclusiones); tampoco si el proveedor desarrolla las integraciones end‑to‑end o consume interfaces ya operativas.
Fundamento técnico‑jurídico. La ambigüedad beneficia a quien conoce el legado y compromete la comparabilidad. La 7021/22 exige claridad e imparcialidad.
Petitorio.
• Publicar contratos de servicio/endpoint y catálogos (CIS/SMOD/GRA/GIS/HES/MDC), volumetrías y definición completa del 99,5 %;
• Precisar si el proveedor implementa integraciones completas o sólo consume APIs expuestas por ANDE.
20-02-2026
18-05-2026
5) Volumetría, datos maestros y alcance de integraciones no definidos
Hecho/Observación. No se publican volumetrías (OT/mes por sistema), catálogos/IDs homologados, criterios de georreferenciación, ambientes (DEV/QA/PROD), ni detalle del 99,5 % (componentes, medición, exclusiones); tampoco si el proveedor desarrolla las integraciones end‑to‑end o consume interfaces ya operativas.
Fundamento técnico‑jurídico. La ambigüedad beneficia a quien conoce el legado y compromete la comparabilidad. La 7021/22 exige claridad e imparcialidad.
Petitorio.
• Publicar contratos de servicio/endpoint y catálogos (CIS/SMOD/GRA/GIS/HES/MDC), volumetrías y definición completa del 99,5 %;
• Precisar si el proveedor implementa integraciones completas o sólo consume APIs expuestas por ANDE.