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 serán suministrados por el proveedor como si hubiesen sido expresamente mencionados, salvo disposición contraria en el contrato.

Los bienes 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 cambios.

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.

1. 1. . Alcance de los Servicios

El objetivo de los servicios es el diseño y desarrollo de la primera etapa de los sistemas Integrados de la Salud y Seguridad Ocupacional.

En base a los antecedentes del MTESS, se presentan a continuación los objetivos generales del proyecto.

Objetivos Generales

1. Diseño, desarrollo e implementación de un sistema de Registros de Empresas, Profesionales y Agentes en el ámbito de Seguridad Ocupacional.
2. Diseño, desarrollo e implementación de un sistema de Gestion de la Matriz de Riesgos, comunicaciones de Accidentes laborales y Enfermedades Profesionales, conctados con la Fiscalizacion del MTESS.
3. Diseño, desarrollo e implementación de un sistema de seguimiento de las Capacitaciones a las empresas, agentes y Profesionales del área de Salud y Seguridad Ocupacional.

 

 

 

 

Objetivos Específicos

Se presentan a continuación los 5 productos/entregables esperados que corresponden a los objetivos específicos del proyecto.

Nro. del Ítem	Nombre de Ítem	Descripción	Indicador de finalización de Ítem	Perfil de los expertos
1	Registros de Empresas, Profesionales y Agentes en el ámbito de la Salud y Seguridad Ocupacional	Este ítem consiste en el registro de las empresas, sus agentes y profesionales, a los cuales se les otorga un carnet que les autoriza a ejercer la profesión, con una serie de procesos de validación que los acreditan. Aquí también se podrá tener padrones de empresas y profesionales, y otros que le permitirá estar en contacto con los mismos, para asi enviar boletines y otras comunicaciones que haran oportuna la interación con los mismos.	Documento digital con reportes, funcionamiento y operado por el personal ya capacitado de MTESS, incluyendo datos generados desde la base POSTGRESQL El documento deberá incluir las pruebas de generación de reportes, de al menos 10 días, de todos los procesos solicitados.	Expertos en SQL, PHP, Framework PhpRunner de al menos la versión 10.4 en adelante, experiencias en Webservices
2	Gestion de la Matriz de Riesgos, sus comunicaciones de Accidentes laborales y Enfermedades Profesionales	Este ítem se refiere a la carga de una matriz según los estándares, según el tipo de empresa y rubro, para luego dar seguimiento, haciendo un cruzamiento con lo ocurrido y estos mismos conectado a las fiscalizaciones realizadas periodicamente	Sistema de control de seguimiento administrativo de las matrices, con al menos 10 reportes con el Personal Capacitado para su operación	Expertos en SQL, PHP, JavaScript, Framework PhpRunner de al menos la versión 10.4 en adelante, experiencias en Webservices, y Jasper Report
3	Sistema de seguimiento de las Capacitaciones a las empresas, agentes y Profesionales del área	Este Ítem permite la carga de las capacitaciones realizadas a las empresas, agentes y profesionales y de esta manera tener su grado de conocimiento en el área, de acuerdo a su rubro. Esto permitirá a la Direccion saber en que lugar capacitar y los que ya fueron capacitados.	Integracion con las empresas, agentes y profesionales, con sus reportes y el personal capacitado para su operación	Conocimiento de Entorno Web, PHP, Webservices, POSTGRESQL, Framework PhpRunner, Java, Rest API
4	Integración de Bases de datos del REOP, IPS, Fiscalizaciones e identificaciones	. Esta integración consiste en conectar a otras bases de datos por medio de WebServices, al Servicio de Intercambio de Información por medio de la MITIC, a las bases de datos locales, para integrarlo en la plataforma	Documentación de los WebService, Manuales y el los Apis operando.	Webservices, POSTGRESQL, Framework PhpRunner, Java, Rest API
5	Implementación de un tablero de seguimiento y situaciones de los tramites	Elaboración y puesta en marcha de tableros que permitan el control de los procesos, para de esta forma tomar decisiones correctas y oportunas	Por lo menos 5 WorkFlows	Desarrollador con experiencia en implementaciones de Tableros en PHPRUNNER

 

Actividades Incluidas en los Ítems

 

Todas las actividades y entregables deberán registrarse en los informes respectivos los cuales deberán ser aprobados por el contratante.

Para cada uno de los servicios de integración y actualización (ítems más arriba detallados), se deberá ejecutar la siguiente secuencia de actividades. 

Documentos de Planeación de cada Ítem y validación con el MTESS.  A ser presentado a los 3 días del inicio de ejecución del contrato (contado desde la recepción de la orden de servicio).

1. Documento con la especificación de los trabajos a ser realizados en cada Ítem incluyendo lugar de trabajo, horario en caso necesario, forma de registro de actividades, de registro de migraciones, de reportes de trabajo, de horas utilizadas y otros relevantes para lograr el adecuado registro de la volumetría y los Indicadores de éxito de cada ítem.  Este documento deberá incluir el relevamiento de información sobre los sistemas a ser instalados incluyendo las documentaciones de las reuniones, visitas de campo, y documentos de los sistemas para avanzar en los entregables.

 

2. Documento con los requerimientos de acceso a Internet, muebles en caso que apliquen, pedidos de acceso a los sistemas, tablas, bases de datos y otros que requiere para realizar su trabajo.

 

3. Documento por cada ítem con los casos de uso acordados, flujos, pantallas de experiencia de usuario, reportes acordados, módulos de control y log s de acceso.

 

 

4. Formulario de validación de los componentes de infraestructura ya existentes en el proyecto para su utilización para cada ítem, el resultado de la validación deberá presentarse al contratante con el plan de mitigación en caso de presentarse observaciones o requisitos adicionales. De existir componentes faltantes de infraestructura, estos no deberían ser causales de interrupción del proyecto.

 

5. Documento con el plan de cumplimiento de niveles mínimos de servicio especificados y KPI de adopción o uso de los ítems respectivos.

 

6. Documento con el plan de capacitación a funcionarios usuarios del sistema una vez puesto en marcha el sistema.

 

7. Documento con Matriz de responsabilidades del proveedor y el MTESS

 

8. Documento con el cronograma de Trabajo con fechas, responsables y entregables concretos
9. Documento con los nombres y perfil de los especialistas a ser designados, incluyendo su hoja de vida, experiencia en proyectos similares y disponibilidad de tiempo en hs dentro del cronograma.
   2. Requerimientos para el desarrollo de los sistemas de Trazabilidad de Procesos de adquisición, ejecución y pagos a proveedores

El oferente deberá desarrollar la solución de tal manera que:

0. 1. 1. Tenga las siguientes características fundamentales:
1. Los distintos componentes solicitados deberán estar basados en las últimas versiones de las tecnologías para cada caso, así como las mejores prácticas de la industria.  
2. Para los Ítems donde se solicitan desarrollos, una aplicación servidor en el backend escrita en un lenguaje de alta performance, pensada para este tipo de escenarios y usada en los sitios más importantes de Internet con un nivel de carga importante. El lenguaje a elegir deberá ser PHP y como plataforma de desarrollo, el PHPRUnner en sus versiones 10.4 en adelante, explotando sus capacidades de concurrencia y al máximo. Deberá contar con la ayuda de un servidor HTTP. Se deberá escribir un conjunto de Web Services de tipo REST para evitar el overhead que impone el SOAP. Este backend deberá ser capaz de acceder a la información residente en base de datos relacionales (en principio PostgreSQL). Se debe usar HTTPS como protocolo de transporte de tal manera que las sesiones sean encriptadas con el protocolo TLS o SSL y autenticadas. Usará WebSockets de manera transparente. Además, para interacciones entre módulos independientes se deberá usar REDIS, para el intercambio de mensajes de carácter prioritario, y un bróker AMQP para los mensajes que puedan ser tratados en forma de cola. Es deseable el uso de GraphQL en el modelado final para que la mensajería con el frontend sea más eficiente.
3. La aplicación de frontend, que corre en el browser del cliente, debe estar escrita en PHP, HTML5, CSS, JavaScript y ReactJS, y consumirá las APIs de tipo REST que el backend dispone. Todos los gráficos, tablas y listados deberán usar librerías estándares de tal manera que los upgrades, o actualizaciones, posteriores puedan realizarse sin mayores inconvenientes. Esta aplicación deberá ser de tipo SPA (Single Page Application). Deberá disponer, además, de un canal Websocket para intercambio de mensajes de carácter prioritario.

4. El desarrollo de la solución debe ser realizado localmente y poseer soporte local especializado de tal manera que los tiempos de respuestas, en eventuales casos de problemas o en casos de necesidad de cambios urgentes, sean muy bajos. Como esta solución está disponiendo información que se producirá en línea y en tiempo real, es importante que el Líder del Equipo de Desarrollo, o del Soporte Local, sea una persona con amplia experiencia en soluciones de tipo en línea y en tiempo real. Los conceptos de multithreading y/o non-blocking operations deben ser manejados de tal manera que esta plataforma no sea un cuello de botella para la solución completa una vez integrada a la plataforma de transacciones electrónicas.
5. Para los items donde aplique, los sistemas a desarrollar deberán ser modulares y escalables. Se deberán poder agregar módulos de información sin que esto afecte los módulos ya existentes. Se deberá poder mantener la performance si la carga de uso se triplica con respecto a la existente. Esto implica una relación muy estrecha del software de backend, principalmente, con el hardware, sistema operativo y fine tunning del servidor. Los recursos hardware deberán ser elegidos cuidadosamente para tal efecto. Además, en los items donde aplique, se solicita el uso de un sistema operativo open source de tipo Linux, Centos 6.9 o Ubuntu 16, toda vez que sea la última versión de la misma y este optimizada para el servicio que se va a prestar. Así también, el ancho de banda a requerir por el servicio deberá ser elegido de tal manera que complemente el servicio completo con relación a la performance.
6. Para los items donde aplique, se deberá proveer una solución de infraestructura de microservicios basada en Arquitectura Apache, con balanceo de carga del sistema, esperada o evaluada en tiempo real.
7. Para los items donde aplique, para la infraestructura tecnológica se deberán usar todas herramientas de open source. Los puntos V), VI), y VII) se refieren específicamente a este punto.
   1. 2. El estilo de arquitectura provea lo siguiente:
      2. 1. Escalabilidad de la interacción con los componentes. Para los items donde aplique, la solución debe poder crecer exponencialmente sin degradar su rendimiento. Unas variedades de clientes deberán poder acceder ya sea desde estaciones de trabajo, o dispositivos móviles, etc.
         2. Generalidad de interfaces. Para los items donde aplique, cualquier cliente deberá poder interactuar con el servidor HTTP sin ninguna configuración especial.
         3. Puesta en funcionamiento independiente. Donde aplique, la solución deberá prever que los clientes y servidores puedan ser puestos en funcionamiento a lo largo de años. Por tanto, la solución deberá permitir que los servidores antiguos sean capaces de entenderse con clientes actuales y viceversa. Se debe utilizar un protocolo que permita este tipo de características.
         4. Compatibilidad con componentes intermedios. Para los items que aplique, la solución deberá ser compatible con los más populares intermediarios, como lo son varios tipos de proxys para Web. En especial aquellos que se utilizan para mejorar el rendimiento u otros que permiten reforzar las políticas de seguridad, como firewalls o gateways (o pasarelas que permiten encapsular sistemas No Web). Ésta compatibilidad con intermediarios deberá permitir reducir la latencia de interacción, reforzar la seguridad y encapsular otros sistemas.
         4.  
      3. Acceso a las bases de datos debe considerar:

 

Para el acceso a las bases de datos relacionales se deberá usar un ORM (Object Relational Mapping) y para las bases de datos NoSQL debe usarse un ODM (Object Document Mapping).

Creación, temprana, de un mapa de base de datos para identificar los dueños de los datos o tablas, temas de sintaxis y semántica. El mismo deberá ser parte obligatoria del entregable final como parte de la documentación técnica del proyecto.

1. 1. 4. Para los items donde aplique, el modelado de las APIs:

Los APIs deberán ser modelados de acuerdo a los métodos HTTP más importantes, que son PUT, GET, POST y DELETE. Suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE. Las acciones (verbos) CRUD se diseñan para operar con datos atómicos dentro del contexto de una transacción con la base de datos. REST se diseña alrededor de transferencias atómicas de un estado más complejo, tal que puede ser visto como la transferencia de un documento estructurado de una aplicación a otra.

El protocolo HTTP separa las nociones de un servidor y un navegador. Esto permite a la implementación de cada uno variar uno del otro, basándose en el concepto cliente/servidor. Cuando utilizamos REST, HTTP no tiene estado. Cada mensaje contiene toda la información necesaria para comprender la petición cuando se combina el estado en el recurso. Como resultado, ni el cliente ni el servidor necesita mantener ningún estado en la comunicación. Cualquier estado mantenido por el servidor debe ser modelado como un recurso.

La restricción de no mantener el estado puede ser violada mediante cookies que mantienen las sesiones pero se advierte sobre el riesgo a la privacidad y seguridad que frecuentemente surge de su uso, así como la confusión y errores que pueden resultar de las interacciones entre cookies y el uso del botón Go back del navegador. Se debe evitar el uso de cookies, salvo justificación plena.

1. 1. 5. Para los items donde aplique, las pautas a seguir en el diseño de estos servicios Web solicitados basados en REST:

• Identificar todas las entidades conceptuales que se desean exponer como servicio.

• Crear una URL para cada recurso. Los recursos deberían ser nombres no verbos (acciones). Por ejemplo no utilizar esto: http://www.service.com/entities/getEntity?id=001. Como podemos observar, getEntity es un verbo. Mejor utilizar el estilo REST, un nombre: http://www.service.com/entities/001.

• Categorizar los recursos de acuerdo con si los clientes pueden obtener una representación del recurso o si pueden modificarlo. Para el primero, se debe hacer los recursos accesibles utilizando un HTTP GET. Para el último, se debe hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE.

• Todos los recursos accesibles mediante GET no deberían tener efectos secundarios. Es decir, los recursos deberían devolver la representación del recurso. Por tanto, invocar al recurso no debería ser el resultado de modificarlo.

 

Acción	HTTP	SQL	Copy&Paste	Unix Shell
Create	PUT	Insert	Pegar	>
Read	GET	Select	Copiar	<
Update	POST	Update	Pegar después	>>
Delete	DELETE	Delete	Cortar	Del/rm

 

• Ninguna representación debería estar aislada. Es decir, es recomendable poner hipervínculos dentro de la representación de un recurso para permitir a los clientes obtener más información.

• Especificar el formato de los datos de respuesta mediante un esquema (DTD,W3C Schema, ). Para los servicios que requieran un POST o un PUT es aconsejable también proporcionar un esquema para especificar el formato de la respuesta.

• Describir como nuestro servicio ha de ser invocado, mediante un documento WSDL/WADL o simplemente HTML.

En la documentación, las APIs deben ser presentadas de esta forma:

Titulo

El nombre de la llamada API

Ejemplo: Mostrar Todos Los Usuarios

 

URL

La estructura de la URL (solo el path)

/users or /users/:id or /users?id=:id

 

Método

El tipo de petición

GET | POST | DELETE | PUT

 

Parámetros de la URL

Requerido:

id=[entero]

ejemplo: id=12

Opcional:

photo_id=[alfanumerico]

ejemplo: photo_id=2345kj3

 

Parámetros de Datos (en el cuerpo)

Ejemplo:

{

 u : {

 email : [cadena],

 name : [cadena],

 current_password : [alfanumerico]

 password : [alfanumerico],

 password_confirmation : [alfanumerico]

 }

}

{

 u : {

 email : "john@smith.com",

 name : "John",

 current_password : "apassw0rd"

 password : "anewpassw0rd",

 password_confirmation : "anewpassw0rd"

 }

}

Respuesta Exitosa

Que valores esperar.

Example:

Code: 200

Content: { id : 12 }

Respuesta de Error

Que valores esperar.

Example:

Code: 401 NO AUTORIZADO

Content: { error : "Autenticacion" }

OR

Code: 422 Input no procesable

Content: { error : "Email invalido" }

 

Como deben ser los datos de entrada y salida:

En todos los casos los datos deben ser expresados en el formato JSON, que es un formato para el intercambio de datos. Básicamente JSON describe los datos con una sintaxis dedicada que se usa para identificar y gestionar los datos. Una de las mayores ventajas que tiene el uso de JSON es que puede ser leído por cualquier lenguaje de programación. Por lo tanto, puede ser usado para el intercambio de información entre distintas tecnologías.

 

JSON Nombre/Par de Valores

Para asignar a un nombre un valor se deberá usar los dos puntos ‘:’, este separador es el equivalente al igual ('=') de cualquier lenguaje.

"Nombre": Juan Pedro"

Valores JSON

Los tipos de valores que podemos encontrar en JSON son los siguientes:

Un número (entero o float)

Un string (entre comillas simples)

Un booleano (true o false)

Un array (entre corchetes [] )

Un objeto (entre llaves {})

Null

 

Objetos JSON

Los objetos JSON se identifican entre llaves

{ "NombreFruta":"Manzana", "Cantidad":20 }

 

Arrays JSON

En un JSON se pueden incluir arrays, para ellos el contenido del array debe ir entre corchetes []:

{

"Frutas": [

{ "NombreFruta":"Manzana", "cantidad":10 },

{ "NombreFruta":"Pera", "cantidad":20 },

{ "NombreFruta":"Naranja", "cantidad":30 }

]

}

 

1. 3. Requerimientos para el desarrollo Tableros o Dashboards:

1. 1. Cada dashboard debe ser diseñado para un público específico,
   2. Cada dashboard debe proveer una vista de un área o tema específico,
   3. Cada dashboard debe proveer un entendimiento relevante para el público para el cual fue creado,
   4. Cada dashboard debe ser del tipo (estratégico, analítico u operacional), de acuerdo al público para el cual fue creado,
   5. Cada dashboard debe poder visualizarse en una única pantalla.
   6. El diseño de cada dashboard deberá estar basado en la importancia de cada reporte incluido en él, y ordenado, de mayor a menor, según su relevancia.
   7. El dashboard debe ser fácil de entender por el público para el cual fue creado.
   8. Se debe asegurar la consistencia en la información desplegada en los diversos dashboards, y
   9. Se debe asegurar la veracidad y confiabilidad  por medio de una certificación de los datos presentados en todos los dashboards.

 

1. 4.  Composición del Equipo y Requisitos de Calificación de los Expertos Clave

El oferente deberá cumplir con los siguientes criterios:

1. Experiencia en Contratos de empresas públicas y/o privadas que evidencien la provisión de software con enfasis en productos SQL, herramientas de Framework PHP,  características iguales o superiores a lo solicitado, preferentemente donde se demuestre la puesta en marcha de principio a fin, y que incluyan servicios de Integración en los últimos 3 años. Detalle de Experiencia en servicios similares ejecutados, realizados individualmente o en asociación con otras firmas en los últimos 3 años (Formulario  Nº 3), se entiende por servicios similares, a trabajos de Integración de sistemas en empresas públicas o privadas que incluyan conexión con licencias o sistemas, mediante el uso de APIs o web services, además de construcción de bases de datos, lógica de negocios y otros componentes del ciclo de vida de sistemas de información para lograr casos de uso, funciones y procesos de principio a fin que logren los objetivos propuestos. Para demostrar su experiencia, se deberán adjuntar cartas de referencias, contratos, actas de recepción, test de uso, reportes de adopción de usuarios o descripción de los casos de uso implementados, al menos uno de los anteriores.  El contratante podrá pedir ampliar la información o visitar las firmas con el fin de comprobar la experiencia solicitada.
2. Al menos 3 años de experiencia en la utilización de la tecnología conforme a los requerimientos de las integraciones.

 

Asimismo, el oferente debera integrar su equipo con otros profesionales:

 

Gerente del Proyecto

 

El Gerente del Proyecto debe realizar las siguientes actividades:

• Presentación en tiempo y forma de los documentos incluidos en la fase de planeación de los Ítems especificados, según las actividades incluidas para cada Ítem.
• Elaboración de un plan de proyecto de acuerdo a los estándares y marco establecido por el Project Management Institute (PMI). Por ejemplo:
  • Elaboración y aprobación de una Carta de Proyecto (Project Charter),
  • Elaboración y actualización del cronograma de proyecto. Debe incluir gráficos de Gantt, WBS, hitos, distribución de recursos, etc.
  • Identificación de supuestos y riesgos, incluyendo plan de mitigación,
  • Elaboración de un plan de comunicación, capacitación,
  • Etc.
• Seguimiento Diario del Proyecto. (Daily Scrum)
• Identificación y documentación de los sistemas interdependientes y de las credenciales de acceso necesarias para la puesta en marcha de las integraciones en ambiente de producción.
• Desarrollo del Plan de Implementación de Releases en el ambiente de producción.
• Asesoramiento y Acompañamiento durante todo el ciclo de vida del proyecto.
• Presentación mensual de los documentos que prueben el avance de los Ítems
• Aseguramiento de cumplimiento de los KPI de cada Item.

 

Habilidades y Experiencia Requerida del Gerente de Proyecto

• Debe contar con experiencia y especialización en manejo de proyectos. Experiencia demostrada en PMP (Project Management Professional) y/o Scrum Master (requerido).
• Experiencia previa de al menos 5 años como miembro de un equipo para el desarrollo de proyectos de Integración, operación y adopción de tecnologías
• Experiencia en gestión de proyectos durante al menos un año en equipos de desarrollo de software que aplicaban los principios y las prácticas de Scrum o similar, con alto nivel de interaccion con usuarios finales, capacidad de seguirmiento y gestion del cambio, gestion de riesgos de proyectos.
• Excelentes habilidades de comunicación y tutoría.
• Conocimiento de las técnicas Agile: Historia de usuarios , ATDD, TDD, integración continua , pruebas continuas y pruebas automatizadas

Desarrollador Senior para Implementación de Sistemas

 

El  Desarrollador Senior debe realizar las siguientes actividades según el item que aplique:

• Experiencia probada para llevar a cabo todo el desarrollo requerido para este proyecto de WebServices, y programas en lenguaje PHP, Framework PHP, CSS, JavaScript.
• Experiencia para llevar a cabo los desarrollos y lograr los KPI establecidos para cada item.

 

Habilidades y Experiencia Requerida

• Debe contar con título universitario en las carreras de Ingeniería de Sistemas, Análisis de Sistemas o carrera afín.
• Experiencia demostrable de al menos 5 años de trabajo en proyectos de desarrollo e integración de sistemas.
• Experiencia demostrable de al menos 3 años de trabajo en proyectos de diseño, desarrollo y consumo de servicios web y APIs. (XML, JSON, REST, TXT, CSV)
• Experiencia de al menos 3 años de trabajo en proyectos de desarrollo con motores de base de datos SQL.
• Experiencia de al menos 3 años de trabajo en desarrollo de software con lenguajes PHP, HTML5, CSS, JavaScript.
• Debe tener conocimientos avanzados en Bases de Datos Relacionales.

Deseable que tenga conocimiento de la metodología ágil SCRUM

 

1. 5. Plazo de Ejecucion de los servicios: 3 (tres) MESES. La administración del contrato estará a cargo de la Dirección de TIC’s conjuntamente con la Dirección Adminsitrativa
   6. Valor del Contrato y Forma de Pago

Los pagos se realizarán bajo el mecanismo de suma alzada, conforme al cronograma de pagos acordados con el proveedor de los servicios, previa aprobación de las instancias pertinentes, según el siguiente detalle (a modo de ilustración):

• • 1er. Pago: el 20% del monto total adjudicado: contra aprobación del Primer Informe, que incluirá los documentos de planeación requerido, debidamente validados por el MTESS. El pago podrá ser solicitado a partir de los 3 días desde el inicio de la ejecución del contrato.
  • 2do. Pago: el 30% del monto total adjudicado: contra aprobación del Segundo Informe, a partir de los 30 dias desde el inicio ejecución del contrato.
  • 3er. Pago: el 30% del monto total adjudicado: contra aprobación del Tercer Informe, a mas tardas los 60 dias.
  • 4to. Pago: el 20% del monto total adjudicado: contra aprobación del  Informe Final y los servicios recibidos aprobados en su totalidad, a mas tardas a los 90 dias desde el inicio de ejecución del contrato.

 

 

El presente procedimiento ha sido solicitado por la Dirección de TICS del MTESS, a cargo del Sr. Ruben Gonzalez, dentro de los procesos de mejoramiento y aumento de los servicios digitales - no presenciales del MTESS.

 

Se indica ademas, que la necesidad a ser satisfecha mediante esta contratación es la siguiente: "La contratación solicitada se encuentra enfocada en el mejoramiento y aumento de los servicios y plataformas digitales del MTESS, orientado a brindar un acceso mejorado y ampliado a los usuarios de los servicios del MTESS.

 

La planificacion se basa en dar continuidad y fortalecer a procesos anteriores ya efectuados en ejercicios anteriores, iniciados con miras a mejorar los procesos documentales y archivos del MTESS.

 

Las especificaciones técnicas han sido definidas en base a los requerimientos estadarizados y el uso de herramientas estadar aplicadas al desarrollo de software vigentes a las fechas.

NO APLICA

LA PRESTACION DE LOS SERVICIOS INICIA DESDE LOS 5 DIAS HABILES POSTERIORES A LA RECEPCION DE LA ORDEN DE SERVICIOS.

 

SE ESTABLECE EL SIGUIENTE CRONOGRAMA DE TRABAJO.

 

Producto Entregable	Descripción	Plazo posterior a la remisión de la Orden de   Servicio
1er. Entregable	Producto Entregable       Primer Informe, incluyendo los instrumentos/documentos de planeación requerido en las EETT, validados por el MTESS.	A los 3 días
2do. Entregable	Producto Entregable   Segun Orden de Servicios (Segundo Informe)	A los 30 días
3er. Entregable	Producto Entregable   Segun Orden de Servicios (Tercer Informe)	A los 60 días
4to. Entregable	Producto Entregable   Segun Orden de Servicios (Informe Final Servicios Recibidos Aprobados)	A los 90 días

EL CONTRATANTE será el Ministerio de Trabajo, Empleo y Seguridad Social a través de la Dirección Administrativa y la DTIC’s del MTESS.

EL CONTRATANTE brindará AL PROVEEDOR información aclaratoria respecto del alcance de los productos y mantendrá reuniones de trabajo para el análisis y evaluación del desarrollo de los entregables. 

EL PRESTADOR DEL SERVICIO utilizará sus propias instalaciones para la fase de planeación. Todas las tareas de instalación y posteriores podran realizarse in situ en el MTESS. El MTESS dispondrá de espacio para tal efecto. En caso de requerirse, podrá optarse por la modalidad TELETRABAJO para la ejecución de los servicios.

Todos los documentos requeridos, sistemas integrados e informes deberán ser entregados en idioma Español, incluyendo software, manuales, capacitación, interfaces, parametrización y tablas.

Las entregas físicas de informes será en la sede Central del MTESS y dirigidos al Director Administrativo con copia a la DTIC’s, o dónde el disponga.

Las entregas de los productos será en la sede Central del MTESS y dirigidos al Director Administrativo con copia a la DTIC’s, o dónde el disponga

No aplica

No aplica

No aplica

Planificación de indicadores de cumplimiento:

INDICADOR	TIPO	FECHA DE PRESENTACIÓN PREVISTA (se indica la fecha que debe presentar según el PBC)
Informe de ejecución 1	Informe Interno	a los 2 meses del inicio de los servicios.
Informe de ejecución 2	Informe Interno	Como máximo a los 5 dias posteriores a la finalizacion del servicio.

 

La convocante adjudicará el contrato al oferente cuya oferta haya sido evaluada como la más baja y cumpla sustancialmente con los requisitos de las bases y condiciones, siempre y cuando la convocante determine que el oferente está calificado para ejecutar el contrato satisfactoriamente.

1. La adjudicación en los procesos de contratación en los cuales se aplique la modalidad de contrato abierto, se efectuará por las cantidades o montos máximos solicitados en el llamado, sin que ello implique obligación de la convocante de requerir la provisión de esa cantidad o monto durante la vigencia del contrato, obligándose sí respecto de las cantidades o montos mínimos establecidos.

2. En caso de que la convocante no haya adquirido la cantidad o monto mínimo establecido, deberá consultar al proveedor si desea ampliarlo para el siguiente ejercicio fiscal, hasta cumplir el mínimo.

3. Al momento de adjudicar el contrato, la convocante se reserva el derecho a disminuir la cantidad requerida, por razones de disponibilidad presupuestaria u otras razones debidamente justificadas. Estas variaciones no podrán alterar los precios unitarios u otros términos y condiciones de la oferta y de los documentos de la licitación.

En aquellos llamados en los cuales se aplique la modalidad de contrato abierto, cuando la convocante deba disminuir cantidades o montos a ser adjudicados, no podrá modificar el monto o las cantidades mínimas establecidas en las bases de la contratación.

La comunicación de la adjudicación a los oferentes será como sigue:

1. Dentro de los cinco (5) días corridos de haberse resuelto la adjudicación, la convocante comunicará a través del Sistema de Información de Contrataciones Públicas, copia del informe de evaluación y del acto administrativo de adjudicación, los cuales serán puestos a disposición pública en el referido sistema. Adicionalmente el sistema generará una notificación a los oferentes por los medios remotos de comunicación electrónica pertinentes, la cual será reglamentada por la DNCP.

2. En sustitución de la notificación a través del Sistema de Información de Contrataciones Públicas, las convocantes podrán dar a conocer la adjudicación por cédula de notificación a cada uno de los oferentes, acompañados de la copia íntegra del acto administrativo y del informe de evaluación. La no entrega del informe en ocasión de la notificación, suspende el plazo para formular protestas hasta tanto la convocante haga entrega de dicha copia al oferente solicitante.

3. En caso de la convocante opte por la notificación física a los oferentes participantes, deberá realizarse únicamente con el acuse de recibo y en el mismo con expresa mención de haber recibido el informe de evaluación y la resolución de adjudicación.

4. Las cancelaciones o declaraciones desiertas deberán ser notificadas a todos los oferentes, según el procedimiento indicado precedentemente.

5. Las notificaciones realizadas en virtud al contrato, deberán ser por escrito y dirigirse a la dirección indicada en el contrato.

Una vez notificado el resultado del proceso, el oferente tendrá la facultad de solicitar una audiencia a fin de que la convocante explique los fundamentos que motivan su decisión.

La solicitud de audiencia informativa no suspenderá ni interrumpirá el plazo para la interposición de protestas.

La misma deberá ser solicitada dentro de los dos (2) días hábiles siguientes en que el oferente haya tomado conocimiento de los términos del Informe de Evaluación de Ofertas.

La convocante deberá dar respuesta a dicha solicitud dentro de los dos (2) días hábiles de haberla recibido y realizar la audiencia en un plazo que no exceda de dos (2) días hábiles siguientes a la fecha de respuesta al oferente.