Secciones
Versión 2
Versión 3
Diferencias entre las versiones 2 y 3
Adenda
Las modificaciones al presente procedimiento de contratación son los indicados a continuación:
Adenda N°1
Punto 1.
Se modifican las fechas establecidas en el SICP.
Se detectaron modificaciones en las siguientes cláusulas:
Sección: Datos de la licitación
- Idioma de la oferta
Se puede realizar una comparación de esta versión del pliego con la versión anterior en el siguiente enlace: https://www.contrataciones.gov.py/licitaciones/convocatoria/401727-lpn-88-21-adquisicion-herramientas-gestion-auditorias-ad-referendum-1/pliego/2/diferencias/1.html?seccion=adenda
La adenda es el documento emitido por la convocante, mediante la cual se modifican aspectos establecidos en la convocatoria y/o en las bases de la licitación y/o en los contratos suscriptos. La adenda será considerada parte integrante del documento cuyo contenido modifique.
Adenda
Las modificaciones al presente procedimiento de contratación son los indicados a continuación:
ADENDA N° 2
En atención a lo establecido en la sección SUMINISTROS REQUERIDOS ESPECIFICACIONES TÉCNICAS del Pliego de Bases y Condiciones para la LICITACIÓN PÚBLICA NACIONAL N° 88/2021 ADQUISICIÓN DE HERRAMIENTAS DE GESTIÓN DE AUDITORÍAS - ID N° 401.727, cumplimos en informar la modificación al PBC para el presente llamado:
Punto 1
En la Sección SUMINISTROS REQUERIDOS ESPECIFICACIONES TÉCNICA del PBC, el apartado 2 - ESPECIFICACIONES TÉCNICAS ÍTEMS 1 AL 2 queda redactado como sigue
|
Requerimiento |
Descripción Técnica |
Exigido/ Opcional |
Ofrecido |
|
Software de gestión de auditorías (Licencias para usuarios) |
La provisión del software, correspondiente al Ítem Nº 1, incluirá la instalación, configuración, pruebas, puesta en vivo del mismo y la capacitación inicial a usuarios. También se incluyen actualizaciones del software por 24 (veinticuatro) meses. El software debe ser instalado, configurado, probado y puesto en vivo por el Proveedor en el BCP, para tres áreas usuarias independientes (Superintendencia de Bancos, Superintendencia de Seguros y Auditoría Interna). La instalación, configuración, pruebas, puesta en vivo y capacitación inicial a usuarios debe poder realizarse en forma on site u online, de acuerdo a lo que sea requerido por el BCP. |
Exigido |
|
|
Cantidad de licencias |
Licencia para 100 (cien) usuarios internos del BCP. |
Exigido |
|
|
Licenciamiento |
Incluye licencia perpetua (uso de por vida). |
Exigido |
|
|
Actualizaciones |
Incluye actualizaciones, a fin de acceder a nuevas versiones del software que pudieran surgir, por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software. |
Exigido |
|
|
Soporte técnico |
Toda la solución deberá contar con soporte técnico local por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software, debiendo contar el Proveedor con oficina y personal local capacitado al efecto. El soporte técnico debe poder prestarse en forma on site u online, de acuerdo a lo que requiera el BCP. Se entiende por soporte técnico: la capacitación, acompañamiento para registro de datos, asistencia técnica, resolución de problemas y personal técnico responsable por parte del Proveedor. |
Exigido |
|
|
Plataforma Tecnológica |
Los servidores de aplicaciones y de base de datos operarán en un entorno operativo Windows Server 2019 o superior, compatible con la plataforma institucional existente. Bases de datos: Las bases de datos del software deberán ser compatibles las que actualmente emplea el BCP: ORACLE y SQLSERVER. Compatibilidad con Navegador: El software deberá ser compatible con los siguientes navegadores Internet Explorer, Google Chrome y Mozilla Firefox. |
Exigido |
|
|
Seguridad |
El software debe contemplar buenas prácticas OWASP (Open Web Application Security Project). |
Exigido |
|
|
El servidor web debe soportar protocolos tls/https para el tráfico de datos. |
Exigido |
||
|
El software deberá contar con autenticación a través del Directorio Activo (Active Directory). |
Exigido |
||
|
El software deberá incluir medidas que eviten el acceso a la información a través de cualquier herramienta externa (cifrado de datos). |
Exigido |
||
|
Si existieran archivos locales de conexión con la base de datos, éstos deben estar encriptados (para proteger el inicio de sesión y contraseña). |
Exigido |
||
|
La conexión entre bases de datos debe ser encriptada, en caso de que esto no sea posible, se debe permitir la importación y exportación de datos. |
Exigido |
||
|
La base de datos debe soportar la característica de Transparent Data Encryption. |
Exigido |
||
|
Las claves de encriptación deben generarse dinámicamente o utilizar certificados y billeteras protegidas. |
Exigido |
||
|
Auditoría |
Incorporar pistas de auditoría para cualquier acción llevada adelante por cualquier usuario en el software. |
Exigido |
|
|
Las pistas de auditoría deberán estar disponibles en el sistema a través de un módulo específico de forma tal que las instancias correspondientes de las áreas usuarias puedan realizar independientemente controles de las actividades realizadas por los usuarios de su área. |
Exigido |
||
|
El sistema debe permitir la aplicación de las auditorias desde smartphones y tabletas. |
Exigido |
||
|
Perfiles |
El uso del software por parte de los usuarios deberá ser realizado a través de perfiles, para la gestión de auditorías. |
Exigido |
|
|
Deberá ser establecido un perfil de consulta general que pueda acceder a cualquier proceso de auditoría, por área usuaria. |
Exigido |
||
|
Idioma |
El software que implemente la solución debe estar íntegramente en idioma español. |
Exigido |
|
|
Usabilidad |
El sistema debe soportar la característica Mobile Friendly. Debe desplegarse en forma adecuada en cualquier pantalla, sin importar el tamaño ni el dispositivo, soportando función Touch. |
Exigido |
|
|
Implementación |
Antes del inicio del proceso de implementación, para cada área usuaria, el Proveedor deberá brindar acompañamiento a los usuarios, de acuerdo a un plan de implementación que deberá ser elaborado por el Proveedor y aprobado por el Supervisor y la GTIC. Este soporte deberá ser realizado por el Proveedor en forma on site u online, de acuerdo a lo que requiera el BCP. |
Exigido |
|
|
Capacitación Inicial |
Capacitación al personal técnico correspondiente a las tres áreas usuarias, a ser indicado por el Supervisor, en el uso y administración del sistema. |
Exigido |
|
|
Capacitación al personal técnico de la GTIC, en la instalación, configuración, actualización, uso y administración del software. |
Exigido |
||
|
El Proveedor deberá elaborar un plan de capacitación, para las tres áreas usuarias y la GTIC, el cual será aprobado por el Supervisor y la GTIC, antes del inicio de las capacitaciones. |
Exigido |
||
|
Registro de Datos |
Se requerirá apoyo para el registro de datos de tres procesos completos de auditoría por área usuaria, en las etapas de planificación, ejecución de la supervisión, generación de informe final, remisión del informe al auditado, que deberá realizarse por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software. |
Exigido |
|
|
Garantía de Buen Funcionamiento y Calidad |
El Oferente deberá emitir una Garantía de Buen Funcionamiento y Calidad del software ofertado, mediante una Nota en carácter de Declaración Jurada a nombre del Banco Central del Paraguay, en virtud de la cual manifieste que correrá a su cargo, por cuenta propia y sin costo para la Convocante, las reposiciones, sustituciones, reparaciones y/o modificaciones que correspondan, cuando se observasen fallas y/o deficiencias, por causas que le fueran imputables, por el plazo de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software . |
Exigido |
|
|
Garantía del fabricante |
El Oferente deberá presentar la Garantía del Fabricante del software ofertado por el plazo de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software |
Exigido |
|
|
Funcionalidades |
Generales |
||
|
La solución debe permitir gestionar las distintas etapas del proceso de auditoría: análisis y evaluación de riesgos; programación detallada y seguimiento de avance; documentación de papeles de trabajo, emisión de informes, seguimiento a compromisos del auditado. |
Exigido |
||
|
Personalización de descripciones del sistema, pudiendo cambiar de manera transparente y sin acceder al código fuente, cualquier texto del software (opciones de los campos, opciones de menús, etc.) |
Exigido |
||
|
Posibilidad de consumir datos de modelado de procesos ya realizados, en los formatos xlsx u otros similares y/o lenguaje sql. |
Exigido |
|
|
|
Permitir modelar o diseñar flujos de trabajo en notación BPMN donde se describan de forma gráfica los responsables por actividad, las actividades y las reglas de decisión. |
Opcional |
|
|
|
Debe permitir asociar formularios, auditorías, informes de auditorías o cronogramas a los flujos de trabajo para visualizar gráficamente la magnitud de un proceso o conjunto de actividades. |
Opcional |
||
|
La herramienta debe permitir la firma de documentos con firma gráfica y con firma digital. Esta firma digital debe permitir ser configurada para que se haga con documentos individuales o con documentos que deban pasar por un flujo de aprobación/autorización. |
Exigido |
||
|
Posibilidad de realizar teleconferencia para trabajar en agendas y citas de forma online y simultánea. La aplicación puede permitir salas fijas y temporales con configuración de visibilidad y tiempo según los invitados y administradores de las mismas. |
Opcional |
||
|
Posibilidad de crear compromisos vinculados a las auditorías que permitan invitar a participantes mediante el software, indicando el título de la reunión, la fecha, horario y lugar del mismo, quien es el responsable de la reunión y cuáles serán los invitados, así como describir los puntos a tratar o enviar anexos para ser revisados en la invitación. El sistema también podría permitir que los invitados confirmen o no su participación en el compromiso y mostrar de forma estadística los participantes confirmados, ausentes o que aún no han confirmado participación. |
Opcional |
||
|
Planificación de Proyectos |
|||
|
Elaboración de matrices de factores críticos de riesgos que permitan evaluar diversos aspectos de las unidades a auditar, utilizando ponderadores y valorando cada respuesta. |
Exigido |
||
|
Realización de análisis de riesgos por proceso con niveles de probabilidad e impacto parametrizables. |
Exigido |
||
|
Los auditores deben tener cargadas categorías que permitan emitir rankings, durante la planificación a los más idóneos para una auditoría. |
Exigido |
||
|
El sistema debe permitir la visualización de la carga horaria del recurso, alertando de esta forma sobre posibles conflictos de sobreasignación a auditores. |
Exigido |
||
|
Las categorías de los proyectos deben ser ilimitadas y se deben poder configurar en una estructura tipo árbol. |
Exigido |
||
|
El sistema debe permitir la generación de proyectos de auditoría con tablas donde se pueda registrar los siguientes datos:
|
Exigido |
||
|
Posibilidad de mostrar los proyectos de auditoría en forma gráfica mediante el abordaje de una metodología de proyectos. |
Exigido |
||
|
Matriz de campos que permita identificar y actualizar la fecha planificada, revisada y real de al menos 6 hitos. Dichas fechas deben poder consultarse en el módulo de gráficos y reportes y permitir generar diagramas de Gantt. |
Exigido |
||
|
Posibilidad de identificar los eventos efectuados entre las diferentes etapas del workflow, identificando la fecha y hora de programación de la auditoría, cuando fue configurada y confirmada, cuando fue aplicada la auditoría y cuando finalizó. En cada etapa debe quedar consignado quien fue el responsable por ejecutar la etapa |
Exigido |
||
|
Cada proyecto debe contar con roles diferentes parametrizables, por ejemplo: creador del proyecto, gerente de auditoría, jefe de equipo, auditor, auditado u otros roles adicionales. El nombre y permisos de cada rol se configurarán en la matriz de seguridad. Debe permitir la asignación de más de un rol a un usuario y usuarios por rol. |
Exigido |
||
|
El sistema debe permitir la creación de múltiples listas de verificación para ser utilizadas en auditorías. Estas listas de verificación deben poder alinearse y basarse en metodologías, buenas prácticas, estándares, políticas de la Entidad, certificaciones y marcos de gestión. Estos son los puntos que se verificarán durante la auditoría y que también pueden estar vinculados a ítems/requisitos de normas. |
Exigido |
||
|
Análisis y Evaluación de Riesgos |
|||
|
El sistema debe ejecutar el análisis de riesgos siguiendo el método horizontal, vertical o una combinación de ambos a elección del usuario. Asimismo, deberá permitir que el usuario genere evaluaciones específicas. |
Exigido |
||
|
El sistema debe establecer factores de riesgo con su respectiva ponderación o puntuación y asociados a los procesos objeto de la auditoría. |
Exigido |
||
|
Generación de matrices de riesgos que orienten el proceso de programación de la auditoría y sus objetivos, así como alcances. |
Exigido |
||
|
Generación de riesgos y controles de los proyectos asociados a riesgos y controles definidos en una biblioteca. |
Exigido |
||
|
El sistema debe disponer de información histórica para cada riesgo y su correspondiente score dentro de una evaluación de riesgos, que permita conocer la evolución del mismo respecto a evaluaciones pasadas. |
Exigido |
||
|
La sistematización o estandarización de los análisis por medio de formularios o plantillas que puedan ser reutilizadas en diferentes procesos y en distintos proyectos de auditoría. |
Exigido |
||
|
La emisión de reportes impresos con los diferentes datos gestionados por el módulo y cuya generación sea adaptable o personalizable por parte del usuario. |
Exigido |
||
|
Posibilidad de consumir datos de evaluaciones de riesgos ya realizadas, en los formatos xlsx u otros similares y/o lenguaje sql. |
Exigido |
||
|
El sistema debe calcular indicadores clave de desempeño (KPIs) automáticos de conformidad y no conformidad de los programas de auditorías y sus hallazgos. A su vez, debe ser posible consultar el estado de las conformidades de las auditorías, en detalle o en forma de resumen; por categoría, tipo de auditoría, por situación y cualquier otro parámetro especificado. |
Exigido |
||
|
Programación |
|||
|
El sistema debe permitir registrar los diferentes procedimientos de auditoría a ser ejecutados, su fecha de inicio y duración prevista. |
Exigido |
||
|
El sistema debe almacenar los integrantes de los equipos de trabajo asignados para la ejecución del proyecto y sus roles. |
Exigido |
||
|
El sistema debe facilitar el proceso de revisión y aprobación de los procedimientos ejecutados y de los papeles de trabajo que los respaldan, a través de la definición de diferentes categorías y permisos de usuarios. |
Exigido |
||
|
El sistema debe disponer de niveles de revisión múltiple de cada elemento del proyecto, con un esquema de notificaciones que alerte al próximo revisor. |
Exigido |
||
|
El sistema debe mantener los proyectos abiertos y evitar su cierre por parte de los responsables del proyecto de auditoría hasta que se encuentren revisados y aprobados la totalidad de los papeles de trabajo. |
Exigido |
||
|
El sistema debe disponer de facilidades para la emisión de informes por proyecto, tarea, usuario, por fecha y por rango de ellas, así como también la posibilidad de filtrar la información por combinaciones de estos criterios como mínimo. |
Exigido |
||
|
La gestión de los recursos asociados a cada proyecto permitiendo detectar superposiciones de fechas y candidatos idóneos para cada tipo de auditoría. |
Exigido |
||
|
La emisión de informes impresos o exportación de datos que indiquen el costo de la auditoría por tarea, por proyecto, por supervisor u otros criterios. |
Opcional |
||
|
Documentación |
|||
|
El sistema debe permitir la definición de una jerarquía propia de carpetas y asegurar sus archivos a través de la creación y gestión de carpetas para organizar los adjuntos en cada grupo de papeles de trabajo. |
Exigido |
||
|
La posibilidad de adjuntar documentos generados en forma externa por medio de la importación de distintos formatos de documentos electrónicos (odt, .ods, .xls, .doc, .xlsx, .docx, .pdf, ACL, MS Project, etc.), incluyendo documentos de imágenes. |
Exigido |
||
|
Integración con Adobe Acrobat y permitir hiperlinks/marcas de libro dentro de este tipo de documentos. |
Opcional |
||
|
El sistema debe mantener una estructura de punteros o indicadores que automaticen el proceso de referenciación de papeles de trabajo, permitiendo el acceso al documento a través del procedimiento en el que se generó o su referencia en el informe propuesto de auditoría. |
Exigido |
||
|
El sistema debe permitir la realización de hiperlinks entre diferentes proyectos, pudiendo citar elementos que están presentes en proyectos de años anteriores. |
Exigido |
||
|
El sistema debe permitir la búsqueda de papeles de trabajo por medio de categorías y palabras claves, ambas definibles y actualizadas por el administrador de la aplicación. |
Exigido |
||
|
El sistema debe disponer de facilidades para almacenar plantillas con documentación estándar (memos, notas, planillas, listas de verificación o chequeo, papeles de trabajo o informes tipo) en forma de Biblioteca Documental, que pueda administrarse en forma centralizada. |
Exigido |
||
|
El sistema debe permitir la utilización de los modelos de informes predefinidos de la Biblioteca Documental y los papeles de trabajo elaborados por los usuarios para la emisión automatizada del informe final de auditoría, conteniendo el conjunto de referencias a los papeles de trabajo y a los procedimientos que los generaron, en formatos editables o definitivos. |
Exigido |
||
|
El sistema debe disponer de un historial de versiones de los informes de auditoría. |
Exigido |
||
|
El sistema debe permitir registrar quien editó un documento, además de qué parte del documento fue editado. |
Exigido |
||
|
El sistema debe alertar a la siguiente instancia que tiene documentos pendientes de revisión. |
Exigido |
||
|
Disponibilidad de una Biblioteca (actualizable) de estándares y mejores prácticas que facilite la elaboración de planes y programas de auditoría. |
Exigido |
||
|
El sistema debe permitir, por grupos de supervisión, la generación de reportes o consultas en base a diversos criterios. |
Exigido |
||
|
En los hallazgos se debe contar con la siguiente información:
|
Exigido |
||
|
Generación de Reportes |
|||
|
El sistema debe permitir la generación de plantillas de reportes que extraigan datos de las distintas tablas del sistema para la generación de reportes automáticos a medida. |
Exigido |
||
|
El generador de reportes debe permitir al usuario definir reglas lógicas y cálculos a partir de los datos obtenidos. A partir de los datos calculables de las tablas debe permitir utilizar:
|
Opcional |
||
|
El sistema debe generar gráficos de distintos tipos a partir de la información ingresada, en especial mapas de calor y diagramas de Gantt que faciliten la gestión de las auditorías. |
Exigido |
||
|
El sistema debe generar mapas de riesgo a partir de cualquier dato numérico. |
Exigido |
||
|
El sistema debe generar estadísticas detalladas y resumidas así como gráficos relacionados, de los hallazgos realizados como ser: cantidad de hallazgos por criticidad o riesgo, por área, por origen de los hallazgos, por sucursal, por organización, diferencias entre un año y otro, y según cualquier otro criterio parametrizable. |
Exigido |
||
|
Incorporación de cuadros de mando que permitan al usuario generar gráficos y tablas a partir de hallazgos, planes de acción, auditores y proyectos. |
Exigido |
||
|
Toda la información generada debe contar con la posibilidad de ser exportada a formatos MS Excel y PDF. |
Exigido |
||
|
Respuesta de Auditados |
|||
|
El sistema debe permitir el registro de la respuesta por parte de los contactos previamente ingresados en la aplicación. Los contactos podrán ser internos o externos al BCP. |
Exigido |
||
|
La fecha real de cumplimiento debe ser la fecha de culminación de la acción. |
Exigido |
||
|
La fecha esperada de cumplimiento debe ser la fecha en la cual el área auditada se compromete a culminar la acción. |
Exigido |
||
|
La fecha de seguimiento debe ser la fecha en la cual el auditor define un seguimiento para la acción. |
Exigido |
||
|
El estado del plan de acción debe ser parametrizable, como por ejemplo Pendiente, Observación Asumida, Regularizado, Regularizado Parcial, Cerrado, No Vigente, Atendido. |
Exigido |
||
|
El sistema debe generar un historial de respuestas del auditado. |
Exigido |
||
|
El sistema debe disponer de una herramienta web que permita el acceso a un número ilimitado de auditados para la carga de los planes de acción asociados al cumplimiento de las recomendaciones generadas con un cronograma de realización especificado. Asimismo, el sistema debe permitir que la entidad/área auditada pueda responder a la situación actual de los planes de acción derivados de observaciones de los proyectos de auditoría, para los procesos de seguimiento de recomendaciones. |
Exigido |
||
|
Dentro de los planes de acción se podría incorporar presupuesto estimado para su implementación. |
Opcional |
||
|
El sistema debe permitir realizar el monitoreo del proceso de seguimiento de recomendaciones por fecha, por entidad/área y por algún otro parámetro disponible. |
Exigido |
||
|
El sistema debe permitir la emisión de estadísticas resumidas y detalladas de la situación final del proceso de seguimiento de recomendaciones realizado. |
Exigido |
||
|
Los comentarios del auditado deben ser reflejados en los proyectos de auditoría correspondientes. |
Exigido |
||
|
Debe permitir enviar notificaciones por correo electrónico desde la propia plataforma, en las cuales se incluya el link para el acceso directo al asunto notificado. Así también debe contar con alertas vía correo electrónico para auditores y auditados. |
Exigido |
||
|
El sistema debe proporcionar la posibilidad de generar encuestas vía web para entidades/áreas auditadas, procesos de negocio y controles de calidad sobre los papeles de trabajo. |
Exigido |
||
|
Requerimientos Adicionales |
|||
|
El sistema debe ser instalado en un servidor central e implementarse para tres áreas independientes, cuyas tablas mantendrán la base de usuarios, proyectos, bibliotecas de procedimientos, evaluaciones y matrices de riesgos, el repositorio central de documentación y todas las tablas auxiliares necesarias. |
Exigido |
||
|
Los papeles de trabajo deben poder comprimirse por razones de storage y performance. |
Exigido |
||
|
El sistema debe disponer de mecanismos de replicación de información y de sincronización de los equipos portátiles con la base de datos central. |
Exigido |
||
|
El sistema debe permitir el trabajo en forma remota y en línea. |
Exigido |
||
|
El sistema debe permitir el trabajo en forma offline. |
Opcional |
|
|
|
El sistema debe permitir el acceso concurrente de la totalidad de usuarios. |
Exigido |
||
|
El sistema debe permitir administrar como mínimo los siguientes marcos de trabajo: COSO (I al IV), NIIF, COBIT, ISO, MECIP, IAIS. |
Exigido |
||
|
El sistema debe proveer un módulo de cuadro de mando que permita realizar el monitoreo de las auditorias en curso. |
Exigido |
||
|
Se deben parametrizar las implementaciones conforme a las necesidades de cada una de las tres áreas usuarias. |
Exigido |
||
Punto 2
Se modifican las fechas establecidas en el SICP.
Se detectaron modificaciones en las siguientes cláusulas:
Sección: Suministros requeridos - especificaciones técnicas
- Detalles de los productos y/ servicios con las respectivas especificaciones técnicas - CPS
Se puede realizar una comparación de esta versión del pliego con la versión anterior en el siguiente enlace: https://www.contrataciones.gov.py/licitaciones/convocatoria/401727-lpn-88-21-adquisicion-herramientas-gestion-auditorias-ad-referendum-1/pliego/3/diferencias/2.html?seccion=adenda
La adenda es el documento emitido por la convocante, mediante la cual se modifican aspectos establecidos en la convocatoria y/o en las bases de la licitación y/o en los contratos suscriptos. La adenda será considerada parte integrante del documento cuyo contenido modifique.
Adenda
Las modificaciones al presente procedimiento de contratación son los indicados a continuación:
AdendaADENDA N°1 2
Punto
En atención a lo establecido en la sección SUMINISTROS REQUERIDOS ESPECIFICACIONES TÉCNICAS del Pliego de Bases y Condiciones para la LICITACIÓN PÚBLICA NACIONAL N° 88/2021 ADQUISICIÓN DE HERRAMIENTAS DE GESTIÓN DE AUDITORÍAS - ID N° 401.727, cumplimos en informar la modificación al PBC para el presente llamado:
Punto 1
En la Sección SUMINISTROS REQUERIDOS ESPECIFICACIONES TÉCNICA del PBC, el apartado 2 - ESPECIFICACIONES TÉCNICAS ÍTEMS 1. AL 2 queda redactado como sigue
| Requerimiento | Descripción Técnica | Exigido/ Opcional | Ofrecido |
| Software de gestión de auditorías (Licencias para usuarios) | La provisión del software, correspondiente al Ítem Nº 1, incluirá la instalación, configuración, pruebas, puesta en vivo del mismo y la capacitación inicial a usuarios. También se incluyen actualizaciones del software por 24 (veinticuatro) meses. El software debe ser instalado, configurado, probado y puesto en vivo por el Proveedor en el BCP, para tres áreas usuarias independientes (Superintendencia de Bancos, Superintendencia de Seguros y Auditoría Interna). La instalación, configuración, pruebas, puesta en vivo y capacitación inicial a usuarios debe poder realizarse en forma on site u online, de acuerdo a lo que sea requerido por el BCP. | Exigido | |
| Cantidad de licencias | Licencia para 100 (cien) usuarios internos del BCP. | Exigido | |
| Licenciamiento | Incluye licencia perpetua (uso de por vida). | Exigido | |
| Actualizaciones | Incluye actualizaciones, a fin de acceder a nuevas versiones del software que pudieran surgir, por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software. | Exigido | |
| Soporte técnico | Toda la solución deberá contar con soporte técnico local por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software, debiendo contar el Proveedor con oficina y personal local capacitado al efecto. El soporte técnico debe poder prestarse en forma on site u online, de acuerdo a lo que requiera el BCP. Se entiende por soporte técnico: la capacitación, acompañamiento para registro de datos, asistencia técnica, resolución de problemas y personal técnico responsable por parte del Proveedor. | Exigido | |
| Plataforma Tecnológica | Los servidores de aplicaciones y de base de datos operarán en un entorno operativo Windows Server 2019 o superior, compatible con la plataforma institucional existente. Bases de datos: Las bases de datos del software deberán ser compatibles las que actualmente emplea el BCP: ORACLE y SQLSERVER. Compatibilidad con Navegador: El software deberá ser compatible con los siguientes navegadores Internet Explorer, Google Chrome y Mozilla Firefox. | Exigido | |
| Seguridad | El software debe contemplar buenas prácticas OWASP (Open Web Application Security Project). | Exigido | |
| El servidor web debe soportar protocolos tls/https para el tráfico de datos. | Exigido | ||
| El software deberá contar con autenticación a través del Directorio Activo (Active Directory). | Exigido | ||
| El software deberá incluir medidas que eviten el acceso a la información a través de cualquier herramienta externa (cifrado de datos). | Exigido | ||
| Si existieran archivos locales de conexión con la base de datos, éstos deben estar encriptados (para proteger el inicio de sesión y contraseña). | Exigido | ||
| La conexión entre bases de datos debe ser encriptada, en caso de que esto no sea posible, se debe permitir la importación y exportación de datos. | Exigido | ||
| La base de datos debe soportar la característica de Transparent Data Encryption. | Exigido | ||
| Las claves de encriptación deben generarse dinámicamente o utilizar certificados y billeteras protegidas. | Exigido | ||
| Auditoría | Incorporar pistas de auditoría para cualquier acción llevada adelante por cualquier usuario en el software. | Exigido | |
| Las pistas de auditoría deberán estar disponibles en el sistema a través de un módulo específico de forma tal que las instancias correspondientes de las áreas usuarias puedan realizar independientemente controles de las actividades realizadas por los usuarios de su área. | Exigido | ||
| El sistema debe permitir la aplicación de las auditorias desde smartphones y tabletas. | Exigido | ||
| Perfiles | El uso del software por parte de los usuarios deberá ser realizado a través de perfiles, para la gestión de auditorías. | Exigido | |
| Deberá ser establecido un perfil de consulta general que pueda acceder a cualquier proceso de auditoría, por área usuaria. | Exigido | ||
| Idioma | El software que implemente la solución debe estar íntegramente en idioma español. | Exigido | |
| Usabilidad | El sistema debe soportar la característica Mobile Friendly. Debe desplegarse en forma adecuada en cualquier pantalla, sin importar el tamaño ni el dispositivo, soportando función Touch. | Exigido | |
| Implementación | Antes del inicio del proceso de implementación, para cada área usuaria, el Proveedor deberá brindar acompañamiento a los usuarios, de acuerdo a un plan de implementación que deberá ser elaborado por el Proveedor y aprobado por el Supervisor y la GTIC. Este soporte deberá ser realizado por el Proveedor en forma on site u online, de acuerdo a lo que requiera el BCP. | Exigido | |
| Capacitación Inicial | Capacitación al personal técnico correspondiente a las tres áreas usuarias, a ser indicado por el Supervisor, en el uso y administración del sistema. | Exigido | |
| Capacitación al personal técnico de la GTIC, en la instalación, configuración, actualización, uso y administración del software. | Exigido | ||
| El Proveedor deberá elaborar un plan de capacitación, para las tres áreas usuarias y la GTIC, el cual será aprobado por el Supervisor y la GTIC, antes del inicio de las capacitaciones. | Exigido | ||
| Registro de Datos | Se requerirá apoyo para el registro de datos de tres procesos completos de auditoría por área usuaria, en las etapas de planificación, ejecución de la supervisión, generación de informe final, remisión del informe al auditado, que deberá realizarse por un período de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software. | Exigido | |
| Garantía de Buen Funcionamiento y Calidad | El Oferente deberá emitir una Garantía de Buen Funcionamiento y Calidad del software ofertado, mediante una Nota en carácter de Declaración Jurada a nombre del Banco Central del Paraguay, en virtud de la cual manifieste que correrá a su cargo, por cuenta propia y sin costo para la Convocante, las reposiciones, sustituciones, reparaciones y/o modificaciones que correspondan, cuando se observasen fallas y/o deficiencias, por causas que le fueran imputables, por el plazo de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software . | Exigido | |
| Garantía del fabricante | El Oferente deberá presentar la Garantía del Fabricante del software ofertado por el plazo de 24 (veinticuatro) meses a ser contados a partir de la fecha efectiva de puesta en vivo del software | Exigido | |
| Funcionalidades | Generales | ||
| La solución debe permitir gestionar las distintas etapas del proceso de auditoría: análisis y evaluación de riesgos; programación detallada y seguimiento de avance; documentación de papeles de trabajo, emisión de informes, seguimiento a compromisos del auditado. | Exigido | ||
| Personalización de descripciones del sistema, pudiendo cambiar de manera transparente y sin acceder al código fuente, cualquier texto del software (opciones de los campos, opciones de menús, etc.) | Exigido | ||
| Posibilidad de consumir datos de modelado de procesos ya realizados, en los formatos xlsx u otros similares y/o lenguaje sql. | Exigido |
| |
| Permitir modelar o diseñar flujos de trabajo en notación BPMN donde se describan de forma gráfica los responsables por actividad, las actividades y las reglas de decisión. | Opcional |
| |
| Debe permitir asociar formularios, auditorías, informes de auditorías o cronogramas a los flujos de trabajo para visualizar gráficamente la magnitud de un proceso o conjunto de actividades. | Opcional | ||
| La herramienta debe permitir la firma de documentos con firma gráfica y con firma digital. Esta firma digital debe permitir ser configurada para que se haga con documentos individuales o con documentos que deban pasar por un flujo de aprobación/autorización. | Exigido | ||
| Posibilidad de realizar teleconferencia para trabajar en agendas y citas de forma online y simultánea. La aplicación puede permitir salas fijas y temporales con configuración de visibilidad y tiempo según los invitados y administradores de las mismas. | Opcional | ||
| Posibilidad de crear compromisos vinculados a las auditorías que permitan invitar a participantes mediante el software, indicando el título de la reunión, la fecha, horario y lugar del mismo, quien es el responsable de la reunión y cuáles serán los invitados, así como describir los puntos a tratar o enviar anexos para ser revisados en la invitación. El sistema también podría permitir que los invitados confirmen o no su participación en el compromiso y mostrar de forma estadística los participantes confirmados, ausentes o que aún no han confirmado participación. | Opcional | ||
| Planificación de Proyectos | |||
| Elaboración de matrices de factores críticos de riesgos que permitan evaluar diversos aspectos de las unidades a auditar, utilizando ponderadores y valorando cada respuesta. | Exigido | ||
| Realización de análisis de riesgos por proceso con niveles de probabilidad e impacto parametrizables. | Exigido | ||
| Los auditores deben tener cargadas categorías que permitan emitir rankings, durante la planificación a los más idóneos para una auditoría. | Exigido | ||
| El sistema debe permitir la visualización de la carga horaria del recurso, alertando de esta forma sobre posibles conflictos de sobreasignación a auditores. | Exigido | ||
| Las categorías de los proyectos deben ser ilimitadas y se deben poder configurar en una estructura tipo árbol. | Exigido | ||
| El sistema debe permitir la generación de proyectos de auditoría con tablas donde se pueda registrar los siguientes datos:
| Exigido | ||
| Posibilidad de mostrar los proyectos de auditoría en forma gráfica mediante el abordaje de una metodología de proyectos. | Exigido | ||
| Matriz de campos que permita identificar y actualizar la fecha planificada, revisada y real de al menos 6 hitos. Dichas fechas deben poder consultarse en el módulo de gráficos y reportes y permitir generar diagramas de Gantt. | Exigido | ||
| Posibilidad de identificar los eventos efectuados entre las diferentes etapas del workflow, identificando la fecha y hora de programación de la auditoría, cuando fue configurada y confirmada, cuando fue aplicada la auditoría y cuando finalizó. En cada etapa debe quedar consignado quien fue el responsable por ejecutar la etapa | Exigido | ||
| Cada proyecto debe contar con roles diferentes parametrizables, por ejemplo: creador del proyecto, gerente de auditoría, jefe de equipo, auditor, auditado u otros roles adicionales. El nombre y permisos de cada rol se configurarán en la matriz de seguridad. Debe permitir la asignación de más de un rol a un usuario y usuarios por rol. | Exigido | ||
| El sistema debe permitir la creación de múltiples listas de verificación para ser utilizadas en auditorías. Estas listas de verificación deben poder alinearse y basarse en metodologías, buenas prácticas, estándares, políticas de la Entidad, certificaciones y marcos de gestión. Estos son los puntos que se verificarán durante la auditoría y que también pueden estar vinculados a ítems/requisitos de normas. | Exigido | ||
| Análisis y Evaluación de Riesgos | |||
| El sistema debe ejecutar el análisis de riesgos siguiendo el método horizontal, vertical o una combinación de ambos a elección del usuario. Asimismo, deberá permitir que el usuario genere evaluaciones específicas. | Exigido | ||
| El sistema debe establecer factores de riesgo con su respectiva ponderación o puntuación y asociados a los procesos objeto de la auditoría. | Exigido | ||
| Generación de matrices de riesgos que orienten el proceso de programación de la auditoría y sus objetivos, así como alcances. | Exigido | ||
| Generación de riesgos y controles de los proyectos asociados a riesgos y controles definidos en una biblioteca. | Exigido | ||
| El sistema debe disponer de información histórica para cada riesgo y su correspondiente score dentro de una evaluación de riesgos, que permita conocer la evolución del mismo respecto a evaluaciones pasadas. | Exigido | ||
| La sistematización o estandarización de los análisis por medio de formularios o plantillas que puedan ser reutilizadas en diferentes procesos y en distintos proyectos de auditoría. | Exigido | ||
| La emisión de reportes impresos con los diferentes datos gestionados por el módulo y cuya generación sea adaptable o personalizable por parte del usuario. | Exigido | ||
| Posibilidad de consumir datos de evaluaciones de riesgos ya realizadas, en los formatos xlsx u otros similares y/o lenguaje sql. | Exigido | ||
| El sistema debe calcular indicadores clave de desempeño (KPIs) automáticos de conformidad y no conformidad de los programas de auditorías y sus hallazgos. A su vez, debe ser posible consultar el estado de las conformidades de las auditorías, en detalle o en forma de resumen; por categoría, tipo de auditoría, por situación y cualquier otro parámetro especificado. | Exigido | ||
| Programación | |||
| El sistema debe permitir registrar los diferentes procedimientos de auditoría a ser ejecutados, su fecha de inicio y duración prevista. | Exigido | ||
| El sistema debe almacenar los integrantes de los equipos de trabajo asignados para la ejecución del proyecto y sus roles. | Exigido | ||
| El sistema debe facilitar el proceso de revisión y aprobación de los procedimientos ejecutados y de los papeles de trabajo que los respaldan, a través de la definición de diferentes categorías y permisos de usuarios. | Exigido | ||
| El sistema debe disponer de niveles de revisión múltiple de cada elemento del proyecto, con un esquema de notificaciones que alerte al próximo revisor. | Exigido | ||
| El sistema debe mantener los proyectos abiertos y evitar su cierre por parte de los responsables del proyecto de auditoría hasta que se encuentren revisados y aprobados la totalidad de los papeles de trabajo. | Exigido | ||
| El sistema debe disponer de facilidades para la emisión de informes por proyecto, tarea, usuario, por fecha y por rango de ellas, así como también la posibilidad de filtrar la información por combinaciones de estos criterios como mínimo. | Exigido | ||
| La gestión de los recursos asociados a cada proyecto permitiendo detectar superposiciones de fechas y candidatos idóneos para cada tipo de auditoría. | Exigido | ||
| La emisión de informes impresos o exportación de datos que indiquen el costo de la auditoría por tarea, por proyecto, por supervisor u otros criterios. | Opcional | ||
| Documentación | |||
| El sistema debe permitir la definición de una jerarquía propia de carpetas y asegurar sus archivos a través de la creación y gestión de carpetas para organizar los adjuntos en cada grupo de papeles de trabajo. | Exigido | ||
| La posibilidad de adjuntar documentos generados en forma externa por medio de la importación de distintos formatos de documentos electrónicos (odt, .ods, .xls, .doc, .xlsx, .docx, .pdf, ACL, MS Project, etc.), incluyendo documentos de imágenes. | Exigido | ||
| Integración con Adobe Acrobat y permitir hiperlinks/marcas de libro dentro de este tipo de documentos. | Opcional | ||
| El sistema debe mantener una estructura de punteros o indicadores que automaticen el proceso de referenciación de papeles de trabajo, permitiendo el acceso al documento a través del procedimiento en el que se generó o su referencia en el informe propuesto de auditoría. | Exigido | ||
| El sistema debe permitir la realización de hiperlinks entre diferentes proyectos, pudiendo citar elementos que están presentes en proyectos de años anteriores. | Exigido | ||
| El sistema debe permitir la búsqueda de papeles de trabajo por medio de categorías y palabras claves, ambas definibles y actualizadas por el administrador de la aplicación. | Exigido | ||
| El sistema debe disponer de facilidades para almacenar plantillas con documentación estándar (memos, notas, planillas, listas de verificación o chequeo, papeles de trabajo o informes tipo) en forma de Biblioteca Documental, que pueda administrarse en forma centralizada. | Exigido | ||
| El sistema debe permitir la utilización de los modelos de informes predefinidos de la Biblioteca Documental y los papeles de trabajo elaborados por los usuarios para la emisión automatizada del informe final de auditoría, conteniendo el conjunto de referencias a los papeles de trabajo y a los procedimientos que los generaron, en formatos editables o definitivos. | Exigido | ||
| El sistema debe disponer de un historial de versiones de los informes de auditoría. | Exigido | ||
| El sistema debe permitir registrar quien editó un documento, además de qué parte del documento fue editado. | Exigido | ||
| El sistema debe alertar a la siguiente instancia que tiene documentos pendientes de revisión. | Exigido | ||
| Disponibilidad de una Biblioteca (actualizable) de estándares y mejores prácticas que facilite la elaboración de planes y programas de auditoría. | Exigido | ||
| El sistema debe permitir, por grupos de supervisión, la generación de reportes o consultas en base a diversos criterios. | Exigido | ||
| En los hallazgos se debe contar con la siguiente información:
| Exigido | ||
| Generación de Reportes | |||
| El sistema debe permitir la generación de plantillas de reportes que extraigan datos de las distintas tablas del sistema para la generación de reportes automáticos a medida. | Exigido | ||
| El generador de reportes debe permitir al usuario definir reglas lógicas y cálculos a partir de los datos obtenidos. A partir de los datos calculables de las tablas debe permitir utilizar:
| Opcional | ||
| El sistema debe generar gráficos de distintos tipos a partir de la información ingresada, en especial mapas de calor y diagramas de Gantt que faciliten la gestión de las auditorías. | Exigido | ||
| El sistema debe generar mapas de riesgo a partir de cualquier dato numérico. | Exigido | ||
| El sistema debe generar estadísticas detalladas y resumidas así como gráficos relacionados, de los hallazgos realizados como ser: cantidad de hallazgos por criticidad o riesgo, por área, por origen de los hallazgos, por sucursal, por organización, diferencias entre un año y otro, y según cualquier otro criterio parametrizable. | Exigido | ||
| Incorporación de cuadros de mando que permitan al usuario generar gráficos y tablas a partir de hallazgos, planes de acción, auditores y proyectos. | Exigido | ||
| Toda la información generada debe contar con la posibilidad de ser exportada a formatos MS Excel y PDF. | Exigido | ||
| Respuesta de Auditados | |||
| El sistema debe permitir el registro de la respuesta por parte de los contactos previamente ingresados en la aplicación. Los contactos podrán ser internos o externos al BCP. | Exigido | ||
| La fecha real de cumplimiento debe ser la fecha de culminación de la acción. | Exigido | ||
| La fecha esperada de cumplimiento debe ser la fecha en la cual el área auditada se compromete a culminar la acción. | Exigido | ||
| La fecha de seguimiento debe ser la fecha en la cual el auditor define un seguimiento para la acción. | Exigido | ||
| El estado del plan de acción debe ser parametrizable, como por ejemplo Pendiente, Observación Asumida, Regularizado, Regularizado Parcial, Cerrado, No Vigente, Atendido. | Exigido | ||
| El sistema debe generar un historial de respuestas del auditado. | Exigido | ||
| El sistema debe disponer de una herramienta web que permita el acceso a un número ilimitado de auditados para la carga de los planes de acción asociados al cumplimiento de las recomendaciones generadas con un cronograma de realización especificado. Asimismo, el sistema debe permitir que la entidad/área auditada pueda responder a la situación actual de los planes de acción derivados de observaciones de los proyectos de auditoría, para los procesos de seguimiento de recomendaciones. | Exigido | ||
| Dentro de los planes de acción se podría incorporar presupuesto estimado para su implementación. | Opcional | ||
| El sistema debe permitir realizar el monitoreo del proceso de seguimiento de recomendaciones por fecha, por entidad/área y por algún otro parámetro disponible. | Exigido | ||
| El sistema debe permitir la emisión de estadísticas resumidas y detalladas de la situación final del proceso de seguimiento de recomendaciones realizado. | Exigido | ||
| Los comentarios del auditado deben ser reflejados en los proyectos de auditoría correspondientes. | Exigido | ||
| Debe permitir enviar notificaciones por correo electrónico desde la propia plataforma, en las cuales se incluya el link para el acceso directo al asunto notificado. Así también debe contar con alertas vía correo electrónico para auditores y auditados. | Exigido | ||
| El sistema debe proporcionar la posibilidad de generar encuestas vía web para entidades/áreas auditadas, procesos de negocio y controles de calidad sobre los papeles de trabajo. | Exigido | ||
| Requerimientos Adicionales | |||
| El sistema debe ser instalado en un servidor central e implementarse para tres áreas independientes, cuyas tablas mantendrán la base de usuarios, proyectos, bibliotecas de procedimientos, evaluaciones y matrices de riesgos, el repositorio central de documentación y todas las tablas auxiliares necesarias. | Exigido | ||
| Los papeles de trabajo deben poder comprimirse por razones de storage y performance. | Exigido | ||
| El sistema debe disponer de mecanismos de replicación de información y de sincronización de los equipos portátiles con la base de datos central. | Exigido | ||
| El sistema debe permitir el trabajo en forma remota y en línea. | Exigido | ||
| El sistema debe permitir el trabajo en forma offline. | Opcional |
| |
| El sistema debe permitir el acceso concurrente de la totalidad de usuarios. | Exigido | ||
| El sistema debe permitir administrar como mínimo los siguientes marcos de trabajo: COSO (I al IV), NIIF, COBIT, ISO, MECIP, IAIS. | Exigido | ||
| El sistema debe proveer un módulo de cuadro de mando que permita realizar el monitoreo de las auditorias en curso. | Exigido | ||
| Se deben parametrizar las implementaciones conforme a las necesidades de cada una de las tres áreas usuarias. | Exigido | ||
Punto 2
Se modifican las fechas establecidas en el SICP.
Se detectaron modificaciones en las siguientes cláusulas:
Sección: Datos de la licitaciónSuministros requeridos - especificaciones técnicas
Idioma de la oferta- Detalles de los productos y/ servicios con las respectivas especificaciones técnicas - CPS
Se puede realizar una comparación de esta versión del pliego con la versión anterior en el siguiente enlace: https://www.contrataciones.gov.py/licitaciones/convocatoria/401727-lpn-88-21-adquisicion-herramientas-gestion-auditorias-ad-referendum-1/pliego/2/diferencias/1.html?seccion=adendahttps://www.contrataciones.gov.py/licitaciones/convocatoria/401727-lpn-88-21-adquisicion-herramientas-gestion-auditorias-ad-referendum-1/pliego/3/diferencias/2.html?seccion=adenda
La adenda es el documento emitido por la convocante, mediante la cual se modifican aspectos establecidos en la convocatoria y/o en las bases de la licitación y/o en los contratos suscriptos. La adenda será considerada parte integrante del documento cuyo contenido modifique.