Web viewLa solución a nivel de base de datos Oracle debe operar bajo el ... Se debe entregar manual de contingencias que contenga una descripción de los procedimientos

Formatos Pliego de Condiciones – Invitación pública para contratar la adquisición, implantación y puesta en operación de la primera fase de una solución integral de gestión documental, en ambiente web, para la Universidad Nacional de Colombia.

FORMATO No. 1 CARTA DE PRESENTACIÓN DE LA PROPUESTA

Bogotá D.C., [día] de [mes] de [año]

SeñoresUNIVERSIDAD NACIONAL DE COLOMBIACiudad.

Referencia: Invitación pública para contratar la adquisición, implantación y puesta en operación de la primera fase de una solución Integral de gestión documental, en ambiente Web, para la Universidad Nacional de Colombia

El (Los) suscrito (s) [xxx nombre del PROPONENTE xxx], de acuerdo con las condiciones que se estipulan en el presente pliego de condiciones, presento la siguiente PROPUESTA para participar en la invitación referenciada, y en caso de que la UNIVERSIDAD NACIONAL DE COLOMBIA me asigne el contrato, objeto de la presente Invitación, me comprometo a suscribirla en los términos aquí establecidos.

Declaro así mismo:1. Que esta propuesta y el contrato que llegare a celebrarse solo compromete al y/o a los aquí

firmantes, o a la persona jurídica que representa(n).2. Que ninguna entidad o persona distinta de los firmantes tienen interés comercial en esta

propuesta ni en el contrato que de ella se derive.3. Que conozco la información general y especial y demás documentos del pliego de condiciones

y aceptamos los requisitos en ellos contenidos.4. Que hemos recibido las siguientes adendas (si las hubo) y aceptamos su contenido:

Adenda No. _____ de fecha ___________________Adenda No. _____ de fecha ___________________Adenda No. _____ de fecha ___________________

5. Que hemos recibido los siguientes informes sobre respuestas a observaciones (si los hubo) y aceptamos su contenido:

Informe de respuestas a observaciones, de fecha __________Informe de respuestas a observaciones, de fecha __________Informe de respuestas a observaciones, de fecha __________

6. Que me comprometo a cumplir con el objeto de conformidad con lo solicitado en el presente pliego de condiciones, en un plazo de XXXX meses, contados a partir de fecha de suscripción del Acta de inicio, previo cumplimiento de todos los requisitos de perfeccionamiento, legalización y ejecución.

7. Que si mi propuesta es seleccionada, me comprometo a aportar los documentos requeridos para la elaboración, suscripción y legalización del contrato, dentro de los términos señalados para ello.

8. Que no me encuentro incurso en causal alguna de inhabilidad e incompatibilidad de las señaladas en la ley y la Constitución Política y no me encuentro en ninguno de los eventos de prohibiciones especiales para contratar con entidades públicas.

9. Que la sociedad a la que represento no ha sido multada ni sancionada, dentro de los dos años anteriores a la fecha de expedición del RUP, en relación con el objeto contractual de la presente invitación.

10. Que la vigencia de nuestra propuesta es 90 días calendario contados a partir de la fecha de cierre de la presente invitación.

11. Que la siguiente propuesta consta de [número de folios] folios debidamente numerados.

Bogotá D.C., Febrero 10 de 2012 Página 1 de 30


Cordialmente,

___________________________Firma Representante Legal Nombre del Representante Legal: [ ]Cédula de Ciudadanía del Representante Legal No. [ ] de [ ]Nombre o Razón Social del PROPONENTE: [ ]NIT del PROPONENTE: [ ]Dirección: [ ]Ciudad: [ ]Teléfono: [ ]Fax: [ ]Correo Electrónico: [ @ ]

NOTA: Ninguna estipulación de esta Carta de Presentación, reemplaza la información o documentación exigida en el pliego de condiciones.

(Fin Formato No. 1)



FORMATO No. 2MATRIZ DE COSTOS Y TIEMPO DE EJECUCIÓN DEL PROYECTO

Diligenciar un cuadro en Excel en el cual describa el servicio a suministrar, cantidad, el costo unitario, IVA y costo total. Se relaciona el siguiente modelo:

DESCRIPCION DEL SERVICIO O BIEN A SUMINISTRAR SITIO

Columnas que debe diligenciar el PROPONENTE

CANTIDADUNIDAD DE MEDIDA / DETALLE

VALOR UNITARIO

VALOR TOTAL IVA VALOR

TOTAL + IVA

SOFTWARE

LICENCIAS

Licencia del Aplicativo. 150 Usuarios

SERVICIOS PROFESIONALES

Instalación, configuración y puesta a punto de la solución.

Desarrollo de Interfaces 3

Consultoría Horas

CAPACITACIÓN

Capacitación por Sede

Nivel Nacional y Bogotá Bogotá Horas

Medellín Medellín Horas

Manizales Manizales Horas

HARDWARE

SERVIDORES

Servidor de Aplicaciones Ubicado en Bogotá 1

Linux, Solaris o Windows

Server



DESCRIPCION DEL SERVICIO O BIEN A SUMINISTRAR SITIO

Columnas que debe diligenciar el PROPONENTE

CANTIDADUNIDAD DE MEDIDA / DETALLE

VALOR UNITARIO

VALOR TOTAL IVA VALOR

TOTAL + IVA

Servidor Base de Datos Ubicado en Bogotá 1

Sistema Operativo

Linux

Servidor de Archivos (File Server) Ubicado en Bogotá 1

Sistema Operativo

Linux

LICENCIAS

Sistemas operativos servidores 3Sistema

Operativo Linux

Base de Datos 1 Oracle 10g o superior

HARDWARE ADICIONAL

Escáneres Gama media.

Nivel Nacional y Sede Bogotá

Ubicado en Bogotá 3

Centro de DigitalizaciónImpresoras de rótulos Sede Bogotá (3) Ubicado en

Bogotá 3

Lectoras de rótulos Sede Bogotá (3) Ubicado en Bogotá 3

Escáneres Gama baja.Nivel Nacional (3), Sedes: Bogotá (4), Medellín (1),

Manizales (1)

Ubicado en cada Sede 9 Puntos de

Digitalización

COSTO TOTAL PROPUESTA ECONÓMICA

Adicionalmente, el PROPONENTE también deberá diligenciar el siguiente cuadro en Excel en el cual describe la duración en tiempo de la implantación y capacitación del proyecto.

SEDE Columnas que debe diligenciar el PROPONENTE



SEMANAS MESESNivel Nacional y Sede Bogotá

Sede MedellínSede Manizales

Aclaraciones adicionales:1. Durante el tiempo de la implantación el PROPONENTE deberá suministrar la infraestructura necesaria para los ambientes de prueba y

desarrollo incluyendo lo necesario para Hardware y Software y será de su propiedad.2. El tiempo para la implantación y capacitación en las ciudades diferentes a Bogotá (Medellín, Manizales) no podrá ser superior a 3 días hábiles

en cada una.

__________________________________________FIRMA REPRESENTANTE LEGAL

(Fin Formato No. 2)



FORMATO No. 3MATRIZ DE REQUERIMIENTOS FUNCIONALES

A continuación se presenta la matriz de requerimientos funcionales y los campos que deben ser diligenciados por el PROPONENTE:

a) La primera columna (Requerimiento) contiene la descripción del requerimiento funcional.b) La segunda columna (Cumple/Ofrece), debe ser diligenciada por el PROPONENTE anotando:

1) CUMPLE para aquellos requerimientos que la solución ofrecida los provee y no requiere desarrollo.2) OFRECE para aquellos requerimientos que la solución ofrecida NO provee pero que los desarrollara durante el tiempo de ejecución del

contrato.c) La tercera columna (Módulo/Folio(s)) debe ser diligenciada por el PROPONENTE con las indicaciones del módulo con el cual cumple con el

requerimiento y el(los) número(s) del folio(s) de la PROPUESTA donde se indica su funcionalidad.

Requerimiento Cumple/Ofrece Módulo/Folio(s)

MÓDULO DE ADMINISTRACIÓN DE COMUNICACIONES OFICIALES (Numeral 6.1.1.).

Registro. El sistema debe realizar el registro a cada comunicación oficial, documento no radicable y envío asignando un prefijo que lo identifique (ej.: RE) y un consecutivo único de registro el cual debe incluir la identificación de la clase de registro que se está generando (ej.: COE – comunicación oficial externa, COI – comunicación oficial Interna, DNR – documento no radicable, ENV – envío), y tener como mínimo los campos descritos en el numeral 6.1.1.1.Radicación. Además del registro, a cada comunicación oficial, debe asignarse un prefijo (ej.: RA) y un consecutivo único de radicación (independiente del código de registro) el cual debe incluir la identificación de la clase de radicación que se está generando (ej.: COE – comunicación oficial externa, COI – comunicación oficial Interna), y tener como mínimo los campos descritos en el numeral 6.1.1.2.Metadatos para registro y radicación que como mínimo se deben manejar los campos descritos en el numeral 6.1.1.3.Registrar las devoluciones de comunicaciones oficiales (papel, documento electrónico), documentos no radicables y envíos con mínimo los campos descritos en el numeral 6.1.1.4.Digitalizar las comunicaciones oficiales recibidas por la UNIVERSIDAD en las ventanillas de correspondencia en los centros de digitalización definidos en el numeral 1.4.2., almacenando el documento obtenido en el servidor de archivos, y asociar el documento con los metadatos de registro y radicación a través del código único de registro asignado al documento. Los documentos que sean anexos de otros deben quedar asociados al código único de registro del documento principal.Generar una etiqueta para el registro y radicación de: comunicaciones oficiales, envíos y documentos no radicables en la cual se incluyan los datos de registro y radicación que la UNIVERSIDAD defina de los señalados en los numerales 6.1.1.1 y 6.1.1.2. La etiqueta debe incluir los códigos únicos de registro y




radicación en códigos de barras y ser imprimible para colocar en documentos de soporte papel. De igual forma debe poder colocarse de manera digital la etiqueta en los documentos electrónicos.Almacenar los documentos electrónicos (digitalizados) en bandejas independientes del módulo de administración de comunicaciones oficiales desde las cuales se puedan gestionar (distribuir).Asignar a cada ventanilla del servicio de correspondencia, bandejas para la administración de los documentos electrónicos, al menos con las descritas en el numeral 6.1.1.8.Manejar automáticamente el estado y los cambios de estado de los documentos electrónicos según la bandeja donde se encuentren y trasladen (digitalizados, asignados, reasignados, devueltos).Controlar a través de la herramienta de flujo de trabajo documental (work flow), la distribución electrónica de los documentos electrónicos desde las ventanillas del servicio de correspondencia hacia las oficinas destinatarias de la UNIVERSIDAD notificando automáticamente a través de la(s) cuenta(s) de correo institucional que se definan al (a los) funcionario(s) destinatario(s).Consultar de manera controlada los documentos, registros y/o radicaciones, ingresados por las ventanillas de correspondencia a través de los metadatos definidos en el numeral 6.1.1.3., permitiendo al sistema indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.1.11.Generar un reporte o planilla con la relación de: comunicaciones oficiales registradas y radicadas, envíos y documentos no radicables que serán entregadas a la(s) oficina(s) destinataria(s) con mínimo los campos descritos en el numeral 6.1.1.12.Permitir desde el Módulo de Gestión Documental, que las oficinas destinatarias de los documentos electrónicos digitalizados, envíos y documentos no radicables recibidos y distribuidos por las ventanillas de correspondencia confirmen su recepción.Capturar la información de los proveedores del servicio de correspondencia de la UNIVERSIDAD con mínimo los campos descritos en el numeral 6.1.1.14.El módulo debe contener la información geográfica nacional (departamentos, municipios) e internacional (países) necesaria para que el operador seleccione el origen y/ o destino de las comunicaciones, envíos y documentos.Para consultas y reportes de Registro y Radicación el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.1.16.Para consultas y reportes de Devoluciones el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.1.17.El módulo debe permitir la programación de los recorridos diarios de las rutas del servicio de distribución física de documentos de correspondencia incorporando como mínimo los campos descritos en el numeral 6.1.1.18.Para consultas y reportes de la programación de recorridos el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.1.19.




MODULO DE ADMINISTRACIÓN DE FLUJOS DOCUMENTALES DE TRABAJO (Numeral 6.1.2.)

El módulo debe permitir diseñar gráficamente flujos documentales asignando actividades como mínimo las descritas en el numeral 6.1.2.1.Administrar las rutas documentales definidas en cada flujo de trabajo (trasladar el documento electrónico entre oficinas, funcionarios y actividades predefinidos) para cualquier documento (tipo documental) y/ o grupos de documentos (series, subseries, expedientes) que sean enrutados desde su ingreso a través del módulo de administración de comunicaciones oficiales o desde una oficina de la UNIVERSIDAD. Siendo posible asignar responsable(s) a cada actividad del flujo.Generar alarmas o alertas y trasmitirlas a través del sistema a las cuentas de correo electrónico institucional de oficinas y funcionarios de cada actividad documental acerca del vencimiento de términos y/o estados de los documentos preestablecidos para la ejecución de la misma y al jefe inmediato cuando no sea atendida una actividad en el tiempo establecido. La alarma debe ser parametrizable permitiendo indicar cuantos días previos a la fecha de vencimiento y con qué frecuencia se hará llegar la notificación a la oficina o funcionario responsable.Generar notificaciones informativas sobre la ejecución de las actividades descritas en el numeral 6.1.2.1. y enviarlas a través del sistema de información y de las cuentas institucionales de correo electrónico predefinidas.Generar flujos documentales fijos (con rutas, actividades y responsables no modificables, excepto por el personal autorizado) y otros flexibles que permitan a los usuarios autorizados decidir en casos particulares incluir variaciones en las rutas, actividades y responsables del flujo documental predefinido.Generar estadísticas y reportes básicos de cada flujo documental sobre tiempos de respuesta a las actividades predefinidas por: documento, expediente, usuario; sobre número de alarmas generadas por: flujo documental, documento, expediente, oficina y usuario.Para consultas y reportes de Flujos Documentales el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos:El módulo debe permitir la generación de varios reportes con mínimo los campos descritos en el numeral 6.1.2.8.

MÓDULO DE GESTIÓN DOCUMENTAL (Numeral 6.1.3.)

Capturar la estructura organizacional de la UNIVERSIDAD con mínimo los niveles y subniveles descritos en el numeral 6.1.3.1.Registrar la modificación de la estructura organizacional de la entidad permitiendo la adición y supresión de oficinas. De estas modificaciones deben guardarse sus registros históricos de tal forma que permita dar trazabilidad a la evolución orgánica de la UNIVERSIDAD.




Contemplar la estructura documental de la UNIVERSIDAD a nivel de: series, subseries, tipos documentales.Permitir la creación de expedientes o carpetas electrónicas que estén asociadas a una serie y/o subserie documental predefinida. A las carpetas de expedientes se asociarán los documentos electrónicos.La solución debe tener una opción para el manejo de las Tablas de Retención Documental – TRD, que permita ejecutar actividades de: ingreso, modificación y eliminación o cambiar de estado a inactiva teniendo en cuenta como mínimo los campos descritos en el numeral 6.1.3.5.Para consultas y reportes de TRD el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.6.La solución debe almacenar las modificaciones realizadas a cualquier campo de la TRD en el tiempo a través del versionamiento de los documentos electrónicos, registrando la trazabilidad a su evolución.Incorporar y conservar los documentos electrónicos de archivo establecidos por las Tablas de Retención Documental garantizando las características de Autenticidad, Fiabilidad e Integridad con el detalle descrito en el numeral 6.1.3.8.El sistema debe realizar el registro de documentos electrónicos (comunicaciones oficiales) elaborados por las oficinas productoras asignando un prefijo que la identifique (ej.: RE) y un consecutivo único de registro el cual debe incluir la identificación de la clase de registro que se está generando (ej.: COE – comunicación oficial externa, COI – comunicación oficial Interna), y tener como mínimo los campos descritos en el numeral 6.1.3.9.El sistema debe permitir la radicación de documentos electrónicos (comunicaciones oficiales) elaborados por las oficinas productoras asignando un prefijo (Ej.: RA) y un consecutivo único de radicación (independiente del código de registro) el cual debe incluir la identificación de la clase de radicación que se está generando (Ej.: COE – comunicación oficial externa, COI – comunicación oficial interna), y tener como mínimo los campos descritos en el numeral 6.1.3.10.Generar una etiqueta para el registro y radicación de comunicaciones oficiales en la cual se incluyan los datos de registro y radicación que la UNIVERSIDAD defina de los señalados en los numerales 6.1.1.1 y 6.1.1.2. La etiqueta debe incluir los códigos únicos de registro y radicación en códigos de barras y ser imprimible para colocar en documentos de soporte papel. De igual forma debe poder colocarse de manera digital la etiqueta en los documentos electrónicos.La solución debe permitir digitalizar documentos de origen externo (no producidos en aplicativos de la UNIVERSIDAD), y los internos que se definan, desde los centros y puntos de digitalización que la UNIVERSIDAD defina. El formato de la imagen del folio obtenido debe ser legible y con un peso no superior a 90 KB. La visualización de la imagen en el sistema debe permitir acciones tales como: rotación, enfocar, desenfocar, colores y gráficos desde el navegador. De igual forma permitir la asignación de metadatos a las imágenes o documentos obtenidos para su consulta y recuperación. Los metadatos para documentos y expedientes del Archivo de Gestión son los definidos en el numeral 6.1.3.17. del presente módulo.Almacenar el documento electrónico digitalizado en una versión de trabajo disponible para los usuarios autorizados durante su gestión desde todos los módulos del sistema, y durante su trámite se puedan ingresar




notas: tipo pos-it, comentarios, observaciones sin que se altere el documento original (documento digitalizado), el cual será archivado en el sistema a través de una opción activada por el usuario que tiene este permiso en su perfil.La solución debe permitir incorporar documentos generados en otros sistemas de información de la UNIVERSIDAD y los elaborados en diferentes aplicaciones, versiones y formatos, especialmente de las aplicaciones de oficina más utilizadas (Microsoft, Open Office, Lotus Notes, etc.), correos electrónicos, fax, escaneados, multiformatos (texto, imagen, video, audio). Además los documentos recibidos vía correo electrónico y fax también deben ser incorporados al sistema en el formato electrónico que defina la UNIVERSIDAD. Estos documentos serán inmodificables a partir de su incorporación al sistema de gestión documental mediante la opción de Archivar activada por el usuario que tiene este permiso en su perfil.Debe permitir asignar los metadatos y llaves de búsqueda que indique la UNIVERSIDAD para identificar y recuperar la información de series, subseries, expedientes y tipos documentales como esta descripto en el numeral 6.1.3.17.La solución debe contar con tecnologías OCR (reconocimiento óptico de caracteres) e ICR (reconocimiento inteligente de caracteres) para capturar de información directamente desde el documento electrónico.Permitir consultar los documentos y expedientes electrónicos a los usuarios autorizados usando varias llaves de búsqueda (combinaciones de varios metadatos), búsqueda full text (opción con la posibilidad de ser solamente habilitada a perfiles definidos de la UNIVERSIDAD), permitiendo consultas y trabajo concurrente multiusuario. El acceso debe darse a los documentos y a sus metadatos. Los metadatos que deben poder asignarse en el módulo de Gestión Documental se encuentran descriptos en el numeral 6.1.3.17.Asignar a cada oficina productora documental bandejas para la administración de los documentos electrónicos con mínimo los estados descriptos en el numeral 6.1.3.18.Manejar automáticamente el estado y los cambios de estado de los documentos electrónicos según la bandeja donde se encuentren y trasladen (recibidos, enviados, asignados, reasignados, clasificados o archivados y de apoyo).Manejar automáticamente el estado y los cambios de estado de los expedientes electrónicos (en trámite, cerrado, archivo de gestión, para eliminar, para seleccionar, Archivo Central, Archivo Histórico).Controlar automáticamente el vencimiento de los periodos de retención establecidos para las agrupaciones documentales (series con sus expedientes), por las TRD generando alarmas y notificaciones una vez se cumplan. Las alarmas y notificaciones deben ser enviadas al responsable de la oficina productora documental y del área de gestión documental a través del propio sistema a la bandeja de entrada y a las cuentas de correo electrónico institucionales.Controlar automáticamente el vencimiento de los periodos de vigencia que se establezcan para algunos documentos (ej.: pólizas contractuales, certificado de antecedentes judiciales, certificado de existencia y representación legal, etc.), indicando el inicio y terminación del plazo e informar al responsable de la oficina productora documental sobre su vencimiento, a través del mismo sistema con una alarma notificación, la cual




también debe enviarse a la cuenta de correo electrónico institucional. La alarma debe ser parametrizable permitiendo indicar cuantos días previos a la fecha de vencimiento y con qué frecuencia se hará llegar la notificación a la oficina o funcionario responsable.Generar automáticamente un índice por expediente que refleje el orden cronológico de incorporación de los documentos asociados a éste y, sea imprimible para usuario autorizado pero inmodificable para todo usuario.Vincular mediante referencias cruzadas la información de un expediente y/o documento almacenado en el sistema con otros dentro del mismo para permitir el acceso a información centralizada sin duplicar los documentos y/o expedientes electrónicos.Cuando un documento este referenciado en dos o más series y expedientes y por disposición sea eliminable en un tiempo menor al requerido en otra serie y expediente se debe transferir el documento a la serie y expediente de mayor tiempo de retención.Para consultas y reportes de documentos y expedientes el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descriptos en el numeral 6.1.3.26.Almacenar de manera temporal los documentos electrónicos de apoyo de las oficinas (no asociados con alguna TRD), controlando su tiempo de almacenamiento y eliminándolos de manera automática cumplido un periodo de tiempo determinado por la UNIVERSIDAD sin ser consultados.Permitir la identificación de los documentos electrónicos de apoyo de las oficinas asociándoles como mínimo los metadatos descriptos en el numeral 6.1.3.28.Contar con definición, identificación y validación de: perfiles de usuario, restricción de accesos según perfiles para cada una de las acciones descritas en cada módulo de la solución. La información de los usuarios que se inactiven por cualquier razón no se podrá eliminar del sistema.Permitir hacer auditorías sobre las modificaciones, transferencias, eliminaciones, impresiones, consultas de los documentos y expedientes electrónicos de manera individualizada para cada uno de ellos y por agrupaciones documentales (series, subseries) como parte de los metadatos o asociados al documento. De esta información debe ser posible generar reportes e informes que muestren como mínimo los campos descriptos en el numeral 6.1.3.30.La solución debe tener una opción para el manejo de las Tablas de Valoración Documental – TVD, que permita ejecutar actividades de: ingreso, modificación y eliminación o cambio de estado a inactiva teniendo en cuenta como mínimo los campos descritos en el numeral 6.1.3.31.Para consultas y reportes de TVD el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descriptos en el numeral 6.1.3.32.La solución debe almacenar las modificaciones realizadas a cualquier campo de la TVD en el tiempo a través del versionamiento de los documentos electrónicos.La solución debe tener una opción para el manejo de los cuadros de Clasificación Documental, que permita ejecutar actividades de: ingreso, modificación y eliminación o cambio de estado a inactiva teniendo en cuenta como mínimo los campos descritos en el numeral 6.1.3.34.




Para consultas y reportes de cuadros de clasificación documental el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descriptos en el numeral 6.1.3.35.La solución debe almacenar las modificaciones realizadas a cualquier campo de los cuadros de clasificación documental en el tiempo a través del versionamiento de los documentos electrónicos.Proveer una estructura de repositorios o archivadores virtuales donde se transfieran y conserven los expedientes electrónicos cuyo estado sea Archivo Central, Archivo Histórico y desde donde sean consultables por los usuarios autorizados.El sistema debe permitir registrar el préstamo de un expediente físico del Archivo de Gestión de la oficina productora documental incorporando como mínimo los campos descritos en el numeral 6.1.3.38.Para consultas y reportes de préstamos de expedientes del Archivo de Gestión el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.39.El sistema debe permitir registrar el préstamo de un expediente físico de Archivo Central incorporando como mínimo los campos descritos en el numeral 6.1.3.40.Para consultas y reportes de préstamos de expedientes del Archivo Central el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.41.Registrar la salida temporal de documentos de Archivo Histórico con mínimo los campos descritos en el numeral 6.1.3.42.Para consultas y reportes de salida temporal de expedientes del Archivo Histórico el sistema debe permitir indexar por varios campos y combinaciones entre ellos como mínimo los campos descritos en el numeral 6.1.3.43.El sistema debe permitir registrar la devolución de expedientes físicos prestados del Archivo de Gestión y Central, y salidas temporales del Archivo Histórico incorporando como mínimo los campos descritos en el numeral 6.1.3.44.Generar alarmas o alertas y trasmitirlas a través del sistema (por ej.: ventanas emergentes) y del correo electrónico institucional a oficinas y funcionarios para alertar sobre el vencimiento del término establecido para la devolución del expediente del Archivo de Gestión, Central o Histórico.Registrar la realización de transferencias documentales primarias de archivos físicos y electrónicos ingresando como mínimo los campos descritos en el numeral 6.1.3.46.Para consultas y reportes la solución debe permitir generar una relación de los expedientes a los cuales se les ha de realizar la transferencia documental primaria de archivos físicos y electrónicos indexando por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.47.Con base a la relación de los expedientes electrónicos a los cuales se les ha de realizar la transferencia documental primaria (ver numeral 6.1.3.46.), la solución debe permitir seleccionar los documentos a transferir que automáticamente cambiaran de estado del expediente de Archivo de Gestión a Archivo Central. Este cambio solo lo podrá hacer el usuario que tiene este permiso dentro de su perfil.




Registrar la realización de transferencias documentales secundarias de archivos físicos y electrónicos ingresando como mínimo los datos descritos en el numeral 6.1.3.49.Para consultas y reportes la solución debe permitir generar una relación de los expedientes a los cuales se les ha de realizar la transferencia documental secundaria de archivos físicos y electrónicos indexando por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.50.Con base a la relación de los expedientes electrónicos a los cuales se les ha de realizar la transferencia documental secundaria (ver numeral 6.1.3.49.), la solución debe permitir seleccionar los documentos a transferir que automáticamente cambiaran de estado del expediente de Archivo Central a Archivo Histórico. Este cambio solo lo podrá hacer el usuario que tiene este permiso dentro de su perfil.El módulo debe permitir la generación de un reporte para transferencias (primarias y secundarias) que incluya como mínimo las columnas descritas en el numeral 6.1.3.52.Registrar la realización de eliminaciones documentales primarias de archivos físicos y electrónicos ingresando como mínimo los campos descritos en el numeral 6.1.3.53.Para consultas y reportes la solución debe permitir generar una relación de los expedientes a los cuales se les ha de realizar la eliminación documental primaria de archivos físicos y electrónicos indexando varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.54.Con base a la relación de los expedientes electrónicos a los cuales se les ha de realizar la eliminación documental primaria (ver numeral 6.1.3.53.), la solución debe permitir seleccionar los expedientes a eliminar y borrarlo físicamente del servidor de base de datos y de archivos. Este cambio solo lo podrá hacer el usuario que tiene este permiso dentro de su perfil.Registrar la realización de eliminaciones documentales secundarias de archivos físicos y electrónicos ingresando como mínimo los campos descritos en el numeral 6.1.3.56.Para consultas y reportes la solución debe permitir generar una relación de los expedientes a los cuales se les ha de realizar la eliminación documental secundaria de archivos físicos y electrónicos indexando varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.57.Con base a la relación de los expedientes electrónicos a los cuales se les ha de realizar la eliminación documental secundaria (ver numeral 6.1.3.56.), la solución debe permitir seleccionar los expedientes a eliminar y borrarlo físicamente del servidor de base de datos y de archivos. Este cambio solo lo podrá hacer el usuario que tiene este permiso dentro de su perfil.El módulo debe permitir la consulta o generación de un reporte de eliminaciones (primarias y secundarias) que incluya como mínimo las columnas descritas en el numeral 6.1.3.59.Registrar los traslados de expedientes físicos y electrónicos por fusión o supresión de oficinas ingresando como mínimo los campos descritos en el numeral 6.1.3.60.Para consultas y reportes la solución debe permitir generar una relación de los expedientes que serán trasladados por fusión o supresión indexando varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.61.




Con base a la relación de los expedientes electrónicos que se han de trasladar por fusión o supresión (ver numeral 6.1.3.60.), la solución debe permitir seleccionar los expedientes a trasladar y asignar la nueva oficina responsable del expediente. Este cambio solo lo podrá hacer el usuario que tiene este permiso dentro de su perfil.El módulo debe permitir la consulta o generación de un reporte por traslados que incluya como mínimo las columnas descritas en el numeral 6.1.3.63.Registrar la donación de colecciones documentales recibidas por el Archivo Histórico ingresando como mínimo los campos descritos en el numeral 6.1.3.64.Para consultas y reportes de colecciones documentales recibidas para el Archivo Histórico, el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.65.El módulo debe permitir la consulta o generación de un reporte para colecciones documentales que incluya como mínimo las columnas descritas en el numeral 6.1.3.66.La solución debe tener una opción para el manejo de los inventarios documentales de la UNIVERSIDAD, que permita ejecutar actividades de: ingreso, modificación y eliminación o cambiar de estado a inactiva teniendo como mínimo los campos descritos en el numeral 6.1.3.67.Para consultas y reportes de inventarios documentales el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.68.El inventario documental del Archivo de Gestión debe ser actualizado automáticamente cada vez que se ingrese o elimine un documento a un expediente en el SIGD.Permitir la graficación e identificación del mobiliario de los Archivos de Gestión, Centrales e Históricos incorporando como mínimo los campos, categorías y su representación gráfica descritas en el numeral 6.1.3.70.Para consultas y reportes del mobiliario de archivos, el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.71.El módulo debe permitir la consulta o generación de un reporte del mobiliario de archivos que incluya como mínimo las columnas descritas en el numeral 6.1.3.72.Registrar las consultas documentales de archivo físico en Archivos de Gestión, Centrales e Históricos con mínimo los campos descritos en el numeral 6.1.3.73.Para consultas y reportes a los registros de consultas documentales de archivo físico en Archivos de Gestión, Centrales e Históricos, el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.74.El módulo debe permitir la consulta o generación de un reporte para los registros de consultas documentales de archivo físico en Archivos de Gestión, Centrales e Históricos que incluya como mínimo las columnas descritas en el numeral 6.1.3.75.




La solución permitirá digitalizar documentos de Archivo Central e Histórico desde uno o más puntos de digitalización que la UNIVERSIDAD defina. El formato de la imagen del folio obtenido debe ser legible y con un peso no superior a 90 KB. La visualización de la imagen en el sistema debe permitir acciones tales como: rotación, enfocar, desenfocar, colores y gráficos desde el navegador. De igual forma permitir la asignación de metadatos a las imágenes o documentos obtenidos para su consulta y recuperación. Los metadatos para documentos y expedientes del Archivo Central son los definidos en el numeral 6.1.3.17. del presente módulo y del Archivo Histórico son los definidos en el numeral 6.1.3.77.Realizar la descripción de unidades documentales de los Archivos Históricos (adoptada en Colombia, mediante Norma Técnica Colombiana ICONTEC No. 4095: 1997), permitiendo la asignación de los metadatos mínimos a archivos físicos, imágenes y/o documentos electrónicos descritos en el numeral 6.1.3.77.Para consultas y reportes de documentos digitalizados en el Archivo Central e Histórico, el sistema debe permitir indexar por varios campos y hacer combinaciones entre ellos con mínimo los campos descritos en el numeral 6.1.3.78.El módulo debe permitir la consulta o generación de un reporte de documentos digitalizados en el Archivo Central e Histórico que incluya como mínimo las columnas descritas en el numeral 6.1.3.79.Todo informe generado en este módulo debe incluir al final el número total de ítems que lo componen independiente del índice seleccionado


(Fin Formato No. 3)



FORMATO No. 4MATRIZ DE REQUERIMIENTOS TÉCNICOS QUE DEBEN SER PROVISTOS

A continuación se presenta la matriz de requerimientos técnicos que deben ser provistos y los datos que deben ser diligenciados por el PROPONENTE:

a) La primera columna (Requerimiento) contiene la descripción del requerimiento técnico.b) La segunda columna (Cumple/Ofrece), debe ser diligenciada por el PROPONENTE anotando:


contrato.c) La tercera columna (tiempo de desarrollo (Horas)) Debe ser diligenciada por el PROPONENTE colocando el número horas necesarias para el

desarrollo.

Requerimientos Cumple/Ofrece

Tiempo desarrollo

(Horas)El PROPONENTE seleccionado deberá implementar interfaces de intercambio de información entre el sistema propuesto y los sistemas de información que tiene la UNIVERSIDAD: Sistema de Información de Talento Humano (SARA), Sistema Financiero (QUIPU) y el Sistema de Directorio LDAP utilizado en la UNIVERSIDAD. Además deberá generar las interfaces requeridas para estos sistemas (esta información será provista por la UNIVERSIDAD) y la solución ofrecida. Las interfaces deben ser desarrolladas teniendo en cuenta la especificación que el PROPONENTE estime técnicamente pertinentes en el tipo de implementación que ofrecerá a la UNIVERSIDAD, de tal forma que se garantice la integridad y la confidencialidad de los mensajes transmitidos. La implementación de las Interfaces se hará con la coordinación y supervisión de la Dirección Nacional de Informática y Comunicaciones de la UNIVERSIDAD.Interface con el Sistema de Talento Humano (SARA)El PROPONENTE deberá desarrollar una interface que interactuará con el Sistema de Talento Humano (SARA) para traer novedades por: ingreso, modificación o marca de inactividad de una oficina en la estructura de la UNIVERSIDAD (Nivel Nacional, Sede, Facultad, Departamento). La UNIVERSIDAD informara los datos requeridos que se deben tener en cuenta el sistema ofrecido para ser actualizados en el SIGD.El PROPONENTE deberá desarrollar una interface que interactuara con el Sistema de Talento Humano (SARA) para traer novedades por ingreso de un empleado a la UNIVERSIDAD. La UNIVERSIDAD informara los datos requeridos que se deben tener en cuenta el sistema ofrecido para ser actualizados en el SIGD.Interface con el Sistema de Financiero (QUIPU)El PROPONENTE deberá desarrollar una interface que interactuará con el Sistema Financiero – QUIPU para traer novedades de nuevos contratos. La UNIVERSIDAD estima que inicialmente se deben tener en



Requerimientos Cumple/Ofrece

Tiempo desarrollo

(Horas)cuenta como mínimo los siguientes campos: Numero de contrato, nombre contratista, NIT, número CDP, número Registro presupuestal. La UNIVERSIDAD informara datos adicionales oportunamente, y que debe tener en cuenta el sistema ofrecido para ser actualizados en el SIGD.Interface con el Sistema de Directorio LDAP de la UNIVERSIDADPara la autenticación de los usuarios se deberá realizar una interface con el Sistema de Directorio LDAP de la UNIVERSIDAD, para asegurar un único punto de control de autenticación. La autorización se debe realizar a nivel de la Base de Datos para el acceso a la aplicación. El sistema ofrecido deberá garantizar el uso de un protocolo seguro para la seguridad de la autenticación

__________________________________________

FIRMA REPRESENTANTE LEGAL

(Fin Formato No. 4)



FORMATO No. 5MATRIZ DE REQUERIMIENTOS TÉCNICOS

A continuación se presenta la matriz de requerimientos técnicos que deben ser diligenciados por el PROPONENTE:

a) La primera columna Código, se refiere al numeral del requerimiento técnico.b) La segunda columna (Requerimiento) contiene la descripción del requerimiento técnico.c) La tercera columna (Cumple/Ofrece), debe ser diligenciada por el PROPONENTE anotando:


contrato.d) La cuarta columna (No. de Folio(s)), debe ser diligenciada por el PROPONENTE con las indicaciones del módulo con el cual cumple con el

requerimiento y el(los) número(s) del folio(s) de la PROPUESTA donde se encuentra.

Código Requerimiento Cumple/Ofrece No. De Folios

ESPECIFICACIONES TÉCNICAS (Numeral 6.2.1.).

6.2.1.1.

El recibo a satisfacción por parte de la UNIVERSIDAD, se realizará una vez puesta en operación la solución incluyendo la entrega de:

a) La versión web de los módulos de Correspondencia y Gestión Documental.b) La versión multinivel de los módulos de Flujo Documental, Administración y

Seguridad.c) Los desarrollos adicionales por parte del PROPONENTE.d) La infraestructura tecnológica, una vez realizadas y aprobadas por la

UNIVERSIDAD, las pruebas técnicas y funcionales correspondientes.6.2.1.2. La solución debe operar sobre la Base de Datos Oracle Versión 10g o superior.6.2.1.3. El PROPONENTE deberá suministrar la infraestructura de servidores (base de datos,

aplicaciones y archivos) necesaria para garantizar la operación de la solución, mínimo hasta el 2015 de acuerdo dimensionamiento estimado en el numeral 1.4. del presente pliego, para cada uno de las Sedes de la UNIVERSIDAD. Así mismo debe suministrar el licenciamiento requerido para garantizar la implantación y puesta en operación de la solución. Las licencias entregadas a la UNIVERSIDAD deberán incluir el soporte y mantenimiento durante doce (12) meses contados a partir de la fecha de terminación del contrato.

El PROPONENTE deberá suministrar a la UNIVERSIDAD la infraestructura del hardware adicional (ver numeral 1.4.) de escáneres, impresoras de rótulos con código de barras y



Código Requerimiento Cumple/Ofrece No. De Folioslectores de rótulos realizando su implantación y su puesta en operación dentro la solución.

Los servidores y el hardware adicional deberán contar como mínimo con las características enunciadas en el Anexo No. 2. La infraestructura suministrada quedará de manera permanente en las instalaciones de la UNIVERSIDAD y será de su propiedad.

6.2.1.4.

El PROPONENTE deberá dimensionar el tamaño de la base de datos y el servidor de aplicación y archivos para la implantación y puesta en operación de la solución con base a la información estimada de la cantidad total de folios (ver numeral 1.4.2. hasta el 1.4.5.) de cada una de las Sedes de la UNIVERSIDAD y proyectar su crecimiento hasta el año 2015.

6.2.1.5.

El PROPONENTE no podrá comercializar, ni vender los desarrollos relacionados en el Formato No. 4 (Requerimientos técnicos que deben ser provistos), por lo tanto los derechos de autor serán de la UNIVERSIDAD y cualquier comercialización deberá estar amparada con los acuerdos a que llegue la UNIVERSIDAD y el PROPONENTE. Para este caso, el PROPONENTE deberá entregar a la UNIVERSIDAD, para su uso y/o modificación el código fuente, objetos y la documentación técnica y funcional generada.

6.2.1.6.

Adicionalmente, de manera independiente, el PROPONENTE debe indicar en caso de disolución de la empresa el procedimiento mediante el cual hará llegar a la UNIVERSIDAD los códigos fuente y objeto del aplicativo (exceptuando los desarrollos del Formato No. 4) que fue implantado y está en producción en la UNIVERSIDAD. Esto no implicará la compra de los derechos de autor sobre el mismo.

6.2.1.7.

La UNIVERSIDAD podrá hacer uso de los programas fuente en caso de disolución de la empresa. Por lo tanto, el PROPONENTE está obligado, de acuerdo con el procedimiento establecido en el punto anterior, a entregar a la UNIVERSIDAD la última versión del código fuente y la documentación actualizada de la versión implantada y que está en producción, para que ella disponga y realice las modificaciones que considere pertinente.

6.2.1.8.

El PROPONENTE deberá indicar el porcentaje (%) equivalente sobre la base del Salario Mínimo Mensual Legal Vigente (SMMLV), cuál es el costo futuro del contrato de mantenimiento y soporte del valor de la licencia del aplicativo, así mismo este valor se podrá incrementar máximo en el IPC del año inmediatamente anterior.

6.2.1.9.El PROPONENTE deberá indicar el porcentaje (%) equivalente sobre la base del Salario Mínimo Mensual Legal Vigente (SMMLV), cuál es el costo por hora de consultoría para efectuar las implantaciones futuras.

6.2.1.10.La solución debe estar completamente desarrollada sobre arquitectura Multinivel, que diferencia las capas de acceso a datos, lógica de negocio e interfaces para soportar ciento cincuenta (150) usuarios, garantizando alta transaccionalidad y escalabilidad.




REQUERIMIENTOS TÉCNICOS DE LA SOLUCIÓN (Numeral 6.2.2.).

Arquitectura (Numeral 6.2.2.1.)

6.2.2.1.1.

La solución debe operar de manera integrada entre los distintos módulos que la componen (Comunicaciones Oficiales, Flujo Documental, Gestión Documental, Administración y Seguridad). Todo dato que ingrese al sistema lo hará exclusivamente por un único sitio y alimentará automáticamente los otros módulos, garantizando la consistencia de la información registrada y evitando duplicidad de la misma.

6.2.2.1.2. El PROPONENTE deberá presentar la arquitectura de operación para el manejo de los documentos por Sede.

6.2.2.1.3.Presentar un estimado del ancho de banda necesario para la gestión de los documentos en las Sedes involucradas con base a la información estimada de la cantidad de folios (ver numeral 1.4.2. hasta el 1.4.5.) de cada una.

6.2.2.1.4. La solución debe permitir que las actualizaciones que se realicen por cambio tecnológico no impactaran negativamente las funcionalidades de la solución que estén en producción.

6.2.2.1.5. La solución debe poder operar en forma independiente al menos en dos (2) modos: pruebas y producción.

6.2.2.1.6.

El PROPONENTE deberá entregar a la UNIVERSIDAD un documento de arquitectura tecnológica de la solución implantada donde se especifique por lo menos lo siguiente:

a) Diagramas de estructura, comportamiento e interacción de la solución, bajo el estándar UML.

b) Protocolos de comunicación.c) Servidor de aplicación utilizado.d) Herramientas de desarrollo y producción, con su respectiva versión

Servidor de Archivos (Numeral 6.2.2.2.)

6.2.2.2.1.El sistema debe tener un servidor de archivos centralizado e independiente del servidor de Base de Datos para almacenar los documentos electrónicos producidos y digitalizados por cada oficina de la UNIVERSIDAD involucrada en el proyecto.

Motor de la Base de Datos (Numeral 6.2.2.3.)

6.2.2.3.1.La Base de Datos debe ser centralizada y permitirá el almacenamiento de los metadatos y referencias de los documentos electrónicos producidos y digitalizados por cada oficina de la UNIVERSIDAD involucrada en el proyecto.

6.2.2.3.2. El modelo de almacenamiento debe manejar el concepto de multiempresa, donde cada nivel de la UNIVERSIDAD se administra como una empresa.




6.2.2.3.3.El PROPONENTE debe indicar la configuración de los perfiles en la Base de Datos (roles) mínimos que requieren ser creados para el modelo de almacenamiento centralizado y descentralizado.

6.2.2.3.4.

La solución debe estar en la capacidad de asegurar que el modelo centralizado de datos y almacenamiento será la única fuente de información como mínimo de los siguientes datos:

a) Número de Registro.b) Numero de Radicación.c) La fecha y hora de una operación (inserción, actualización o eliminación).d) Estructura organizacional.e) Funcionarios.f) Cargos.g) Series.h) Subseries.i) Tipos Documentales.

6.2.2.3.5.La solución debe permitir el manejo de varias estructuras jerárquicas acorde con la estructura de la UNIVERSIDAD (ver numeral 6.1.3.1.), considerando el manejo de multiempresa para cada una de las estructuras.

6.2.2.3.6.

El PROPONENTE deberá estimar cuál es la capacidad de almacenamiento mínima que debe tener el servidor de base de datos y el servidor de archivos con base a la información estimada de la cantidad de folios (ver numeral 1.4.2. hasta el 1.4.5.) de la UNIVERSIDAD, y garantizará que funcione hasta el año 2015.

Sistemas Operacionales (Numeral 6.2.2.4.)6.2.2.4.1. La solución a nivel de base de datos Oracle debe operar bajo el sistema operativo Linux.

6.2.2.4.2. El servidor de aplicaciones debe operar bajo alguno de los siguientes sistemas operativos: Linux, Solaris o Windows 2008 server stand alone o superior.

6.2.2.4.3. Los servidores de archivos deben operar bajo el sistema operativo Linux.Red (Numeral 6.2.2.5.)

6.2.2.5.1.Todas las comunicaciones de la solución (entre los clientes y el servidor, o entre los servidores), deben hacerse a través del protocolo TCP/IP, y no debe depender en manera alguna del hardware y software utilizado.

Servidor de Aplicaciones (Numeral 6.2.2.6.)

6.2.2.6.1. El PROPONENTE debe indicar si utiliza librerías específicas que deban ser instaladas en el servidor de aplicaciones así como si requiere de otros utilitarios para su operación.

6.2.2.6.2. Lenguaje en el que se debe encontrar desarrollado el producto: PHP y/o Java.




6.2.2.6.3. Los requerimientos relacionados en el Formato No. 4, deberá estar desarrollado en tecnología JAVA (especificación JEE5 o superior).

Clientes del sistema (Numeral 6.2.2.7.)

6.2.2.7.1.

El PROPONENTE debe suministrar la respectiva configuración para los clientes, que permitan a la solución operar con tiempos de respuesta aceptables. Para lo cual la UNIVERSIDAD realizara las pruebas de carga con el aplicativo JMETER y los tiempos de respuesta aceptados por la UNIVERSIDAD no debe superar los 4 segundos como tiempo promedio en el percentil 90.

6.2.2.7.2.

La solución debe entregarse funcionando de manera adecuada sobre los siguientes navegadores:

a) Internet Explorer 8.0 o superior.b) Firefox 5.0 o superior.c) Chrome 11.0 o superior

6.2.2.7.3.El PROPONENTE debe indicar cuál es la versión mínima de Microsoft Office que debe tener instalada la estación del trabajo del cliente como aplicación ofimática (Ej.: Office 2003 o superior).

6.2.2.7.4. El sistema debe estar en la capacidad de desactivar automáticamente el login de un usuario cuando éste ha dejado de ingresar a la solución después de dos (2) meses.

Documentación (Numeral 6.2.2.8.)

6.2.2.8.1. Se deben entregar los siguientes manuales de la operación de la solución: técnico, instalación, usuario y parametrización.

6.2.2.8.2. La documentación debe entregarse en medio magnético (Word 2007 o superior) impresa o en html y en español.

6.2.2.8.3.

Para los desarrollos propietarios (Formato No. 4) el PROPONENTE deberá entregar por lo menos la siguiente documentación:

a) Diagramas de Clases.b) Diagramas de Casos de Uso.c) Diagramas de Secuenciad) Diagramas de Estadose) Diseño de la Base de Datos.f) Diccionario de datos de la Base de Datos.g) Documento de Arquitectura.h) Documentación del código de fuente.i) Archivos de configuración e instalación.




6.2.2.8.4.

Se debe entregar un documento con el procedimiento que indique claramente las actividades a ejecutar por parte de la UNIVERSIDAD y el PROPONENTE para las actualizaciones que por cambio tecnológico se requiera realizar, durante la ejecución del contrato y posterior a su puesta en operación.

6.2.2.8.5.Proveer todas las interfaces de usuarios finales en español y la documentación técnica y de usuario final del sistema que debe incluir la descripción de programas y la definición de estándares.

Búsquedas de Información (Numeral 6.2.2.9.)

6.2.2.9.1.

La solución debe manejar múltiples usuarios con sus respectivos niveles de acceso a la información y funciones, así como menús o rutas de llegadas personalizadas; lo anterior de acuerdo con los diferentes requerimientos de la UNIVERSIDAD. A continuación se presentan los mínimos perfiles con funciones a considerar en el sistema:

a) Usuarios Activos: Son los usuarios que interactúan continuamente con el SIGD. Los perfiles con estas funciones se encuentran descritos en el numeral 6.2.2.9.1. literal a).

b) Usuarios de Consulta: Realizan la consulta de la información almacenada en el SIGD sin modificar su contenido. Este grupo debe poder desagregarse a partir de la estructura organizacional de la UNIVERSIDAD (ver numeral 6.1.3.1.). Los perfiles con estas funciones se encuentran descritos en el numeral 6.2.2.9.1. literal b).

c) Administrador: Gestiona los procesos de auditoría, sesiones, roles y usuarios, permisos, copias de seguridad, y la parametrización de la aplicación. Además debe poder consultar la información del sistema.

6.2.2.9.2.Los resultados de las búsquedas de contenido que se realicen deben depender de los privilegios a nivel de acceso a los datos que tengan los usuarios en el modelo de roles de la solución.

6.2.2.9.3. La función de búsqueda debe permitir incluir capacidades avanzadas que incluyan búsquedas por proximidad y búsquedas parametrizables por atributos según el tipo de contenido.

6.2.2.9.4. Debe soportar los operadores “Y”, “O” y “NOT (Negación)” en las búsquedas.6.2.2.9.5. Debe permitir el uso de comodín para representar una letra en la palabra de búsqueda.

Seguridad y manejo (Numeral 6.2.2.10.)

6.2.2.10.1.Los procedimientos de recuperación deben garantizar que solamente las transacciones que no se han completado en el momento de una caída se reversen, y que aquellas que se han completado se recuperen, para garantizar la consistencia de la información.

6.2.2.10.2. La solución debe permitir la definición de roles. Un rol es la combinación de permisos de lectura,



Código Requerimiento Cumple/Ofrece No. De Foliosescritura y borrado sobre un grupo. Los roles deben poder ser asignados a los usuarios con el fin de definir qué permisos tienen los usuarios sobre los grupos.

6.2.2.10.3. La solución debe disponer de módulos especializados para la Administración y Seguridad operados únicamente por el usuario Administrador.

6.2.2.10.4. Los módulos de Administración y Seguridad deben contar con la funcionalidad necesaria para parametrizar el sistema.

6.2.2.10.5.

El módulo de Administración debe contar como mínimo con las siguientes opciones, para gestionar los roles y usuarios:

a) Funcionarios.b) Cargos.c) Estructura Organizacional.

6.2.2.10.6.

El módulo de Seguridad debe contar como mínimo con las siguientes opciones:a) Perfiles de acceso a la base de datos.b) Perfiles de acceso a la aplicación.c) Asignación de perfiles a usuarios.d) Auditoria.e) Copias de Seguridad.f) Gestiones de Sesiones.g) Gestión de contraseñas seguras.

6.2.2.10.7. El manejo de seguridad debe ser complementario al que provea el motor de la base de datos.

6.2.2.10.8.La aplicación debe contar con un módulo de auditoría que deberá permitir parametrizar la auditoria a una o más tablas de la solución, (alguno o todos sus campos), cuando así lo requiera la UNIVERSIDAD.

6.2.2.10.9.

La solución debe llevar registro de auditoría con un contenido mínimo de la siguiente información:

a) Usuario.b) Fecha de la transacción.c) Hora de la transacción.d) Dirección IP desde la cual se hizo la transacción.e) Tabla de la Base de Datos que fue modificada.f) Campo que fue modificado.g) Valor del registro antes y después de la modificación.

6.2.2.10.10.

La solución debe permitir generar salidas en reportes de los registros de auditoría con un contenido mínimo al descrito en el numeral 6.2.2.10.9.

6.2.2.10.11.

La solución debe contar con herramientas que permitan desmontar bloques de información. Así mismo poder recuperarlos si se requieren nuevamente.



Código Requerimiento Cumple/Ofrece No. De Folios6.2.2.10.12.

La solución debe contar con procedimientos claros para su instalación y actualización por cambios.

6.2.2.10.13.

El PROPONENTE debe entregar un documento que describe la forma en que la solución alerta sobre el cumplimiento de periodos preestablecidos para la realización de copias de seguridad (totales e incrementales) de la información almacenada en el SIGD.

6.2.2.10.14.

Se debe entregar manual de contingencias que contenga una descripción de los procedimientos para minimizar los riesgos de pérdida de información y garantizar la continuidad de los procesos sistematizados.

6.2.2.10.15.

Incluir mecanismos de contingencia para preservación de la información (contenido de los documentos) en casos de migración de información por cambio o liberación de nuevas versiones de: sistema de información, cambio de formato, migración de hardware y/o cambio de software base (Sistemas Operacionales, Base de Datos y librerías específicas de la solución).

Actualización de versiones (Numeral 6.2.2.11.)

6.2.2.11.1.El PROPONENTE deberá dar garantía a la solución suministrada a la UNIVERSIDAD por un período mínimo de doce (12) meses, contados a partir de la fecha de suscripción del acta de recibo a satisfacción, suscrita por el Supervisor.

6.2.2.11.2.

Cuando se presenten actualizaciones del sistema operacional, motor de la base de datos o servidor de aplicaciones, y mientras se mantengan compromisos de garantía, el PROPONENTE deberá garantizar que la solución se encuentre en producción en las nuevas versiones en un plazo acordado con la UNIVERSIDAD.

6.2.2.11.3.Cuando se presente una actualización de la solución, el PROPONENTE se compromete a actualizar además la totalidad de la documentación de la misma, suministrada inicialmente a la UNIVERSIDAD así como las respectivas licencias.

6.2.2.11.4. Cuando se presente una actualización de la solución, se debe brindar la capacitación requerida para la correcta operación de la nueva versión, tanto a los usuarios funcionales como técnicos.

Licenciamiento y soporte (Numeral 6.2.2.12.)

6.2.2.12.1.

Se requiere licenciamiento a perpetuidad de 150 usuarios para la UNIVERSIDAD de la solución ofrecida. El PROPONENTE deberá relacionar el costo de licenciamiento. El PROPONENTE deberá entregar a la UNIVERSIDAD los ejecutables y/u objetos del software para su respectiva custodia. Las licencias adicionales (base de datos, sistema operativo, servidor de aplicaciones, escáner, impresoras de rótulos, lectores de rótulos, etc.) deberán ser entregadas a la UNIVERSIDAD y deberán ser perpetuas. La UNIVERSIDAD definirá si a futuro realizará contratos de soporte y mantenimiento sobre dichas licencias.

6.2.2.12.2. El PROPONENTE no podrá comercializar, ni vender los desarrollos relacionados en el Formato No. 4, por lo tanto los derechos de autor serán de la UNIVERSIDAD y cualquier



Código Requerimiento Cumple/Ofrece No. De Folioscomercialización deberá estar amparada con los acuerdos a que lleguen la UNIVERSIDAD y el PROPONENTE Para este caso, el PROPONENTE deberá entregar a la UNIVERSIDAD, para su uso y/o modificación el código fuente, objetos y la documentación técnica y funcional generada.

6.2.2.12.3.

El PROPONENTE deberá presentar carta suscrita por el fabricante o propietario del software en la que garantice que el PROPONENTE está autorizado para ofrecer la comercialización y la prestación de los servicios de garantía, soporte y mantenimiento de la solución PROPUESTA. La certificación deberá especificar que el PROPONENTE prestará el servicio de garantía por un periodo mínimo de doce (12) meses contados a partir de la entrega definitiva del producto, la cual se legaliza a partir de la fecha de suscripción del acta de recibo a satisfacción, suscrita por el Supervisor. Adicionalmente, deberá incluir expresamente que el PROPONENTE se encuentra autorizado para prestar el soporte y mantenimiento de la solución por un período mínimo de cinco (5) años. Lo anterior no implica que la UNIVERSIDAD esté obligada a suscribir contratos futuros de soporte y/o mantenimiento sobre la solución adquirida.

6.2.2.12.4.

El PROPONENTE debe garantizar la prestación de los servicios de garantía, soporte y mantenimiento cumpliendo como mínimo con lo estipulado en el Anexo No. 3. Como soporte de lo anterior deberá entregar un documento que describa el esquema de prestación de los servicios de garantía, soporte y mantenimiento.

6.2.2.12.5.

El PROPONENTE deberá indicar el porcentaje (%) equivalente al costo de mantenimiento y soporte, sobre la base del Salario Mínimo Mensual Legal Vigente (SMMLV), en que deberá incurrir la UNIVERSIDAD para la operación del producto adquirido, en relación al valor de las licencias suministradas. Este porcentaje aplicará para el primer año luego de vencida la Garantía y posteriormente dicho valor se podrá incrementar máximo en el IPC del año inmediatamente anterior.

Talento Humano (Numeral 6.2.2.13.)

6.2.2.13.1. El PROPONENTE deberá contemplar el personal solicitado en el Formato No. 6 para desarrollar la totalidad de actividades requeridas para la implantación y puesta en operación de la solución.

6.2.2.13.2. El PROPONENTE deberá contemplar el cronograma y la metodología PROPUESTA a la UNIVERSIDAD para efectuar, la implantación y la puesta en operación de la solución PROPUESTA, incluyendo tiempo de ejecución de cada fase, hitos, responsables y seguimiento del proyecto. Para la elaboración del cronograma el PROPONENTE deberá tener en cuenta que la implantación no podrá ser simultanea entre dos o más sedes, y debe ajustarse al siguiente orden:

a) Nivel Nacional.b) Sede Bogotá.c) Sede Medellín.



Código Requerimiento Cumple/Ofrece No. De Foliosd) Sede Manizales.

Capacitación (Numeral 6.2.2.14.)

6.2.2.14.1.

El PROPONENTE deberá incluir el plan de capacitación del proyecto (ver numeral 1.4.2. hasta el 1.4.5.), y por lo tanto formar parte del cronograma de trabajo, la capacitación y el entrenamiento necesario (funcional y técnico) para la instalación, administración y operación del sistema.

6.2.2.14.2.Debe relacionar por cada módulo, su intensidad (en horas), perfil del usuario a quien va dirigido, número máximo de funcionarios que serán capacitados y material suministrado y necesario para la capacitación.

6.2.2.14.3.Las fechas y el sitio en cada Sede (Bogotá, Medellín y Manizales) donde se dictarán los cursos sobre el manejo de la solución, serán coordinados por la UNIVERSIDAD y el PROPONENTE favorecido con la adjudicación.

6.2.2.14.4.

Debe tenerse en cuenta que para efectos de la implantación de la solución para la serie documental Contratos y Órdenes Contractuales, se requiere la movilización del personal del PROPONENTE a las Sedes de Medellín y Manizales, conforme al programa de trabajo a seguir. Por lo tanto, dentro del valor de la PROPUESTA deberán estar incluidos los gastos de viaje y desplazamiento que se generen por la movilización a éstas. El tiempo para la implantación y capacitación en las sedes mencionadas no podrá ser superior a 3 días hábiles.

6.2.2.14.5. Cuando se presente una actualización de la solución, se debe brindar la capacitación requerida para la correcta operación de la nueva versión, tanto a los usuarios funcionales como técnicos.

Parametrización (Numeral 6.2.2.15.)

6.2.2.15.1.La solución debe ser parametrizable. El usuario con este permiso debe tener la posibilidad, en forma sencilla, de fijar los parámetros que considere necesarios sin requerir cambios en los programas.

6.2.2.15.2. El aplicativo deberá permitir la actualización de los parámetros de tal manera que el sistema se adapte fácilmente a los cambios funcionales y organizacionales de la institución.

6.2.2.15.3. La solución debe permitir definir, a través de su parametrización, cuáles atributos son obligatorios y cuáles opcionales.

6.2.2.15.4. La solución debe permitir la definición de campos obligatorios de metadatos para cargar un documento al SIGD.

6.2.2.15.5. La solución debe permitir definir campos opcionales de metadatos para cargar un documento al SIGD.

6.2.2.15.6. Se debe permitir la definición de los campos a visualizar de metadatos sobre los documentos de acuerdo al perfil que está accediendo el documento.




6.2.2.15.7. La solución debe permitir incorporar la imagen institucional a la interfaz gráfica de acuerdo con el estándar definido por la UNIVERSIDAD (logos, colores, fuentes).


(Fin Formato No. 5)


Pliego de Condiciones – Invitación pública para contratar la adquisición, implantación y puesta en operación de la primera fase de una solución integral de gestión documental, en ambiente web, para la Universidad Nacional de Colombia.

FORMATO No. 6TALENTO HUMANO

Detalle de los requerimientos técnicos admisibles:

6.1. Gerente de Proyecto

Requisito mínimo Modulo / No. de Folio

Función

Responsable de ejecutar la administración, el seguimiento y verificación de las etapas y fases del plan general de trabajo propuesto a la UNIVERSIDAD.

Cantidad de personas 1Dedicación en el proyecto (% de tiempo)

60% en la fase inicial y 40% durante la fase de implantación.

Formación académica Ingeniero de sistemas ó Ingeniero Industrial con Especialización en Gerencia de Proyectos

Experiencia (Años laborando desde la fecha de expedición de la tarjeta profesional)

5 años de participación en proyectos en los cuales se relacionen funciones de gerencia de proyectos de sistemas de información en Gestión Documental, después de expedición de la tarjeta profesional.

6.2. Líder Funcional


Función Coordinar la ejecución e implantación de la solución.

Cantidad de personas 1

Dedicación en el proyecto (% de tiempo)

100% durante todo el proyecto.

Formación Académica Profesional en Archivística ó ciencias de la información ó profesional, técnico o tecnólogo.

Experiencia (Años laborando desde la fecha de grado l)

5 años en actividades de gestión documental, 3 de ellos de participación en proyectos en cada uno de los cuales debe haber cumplido funciones como líder funcional en proyectos similares.


Pliego de Condiciones – Invitación pública para contratar la adquisición, implantación y puesta en operación de la primera fase de una solución integral de gestión documental, en ambiente web, para la Universidad Nacional de Colombia.

6.3. Líder Técnico


FunciónCoordinar la ejecución de todas las etapas técnicas del proyecto y fases de la implantación de la solución.

Cantidad de personas 1

Dedicación en el proyecto (% de tiempo)

100% durante todo el proyecto.

Formación Académica Profesional de Ingeniería de Sistemas

Experiencia (Años laborando desde la fecha de grado profesional )

3 años de participación en proyectos en cada uno de los cuales debe haber cumplido funciones como líder técnico de proyectos similares al objeto de la presente invitación.


(Fin Formato No. 6)


Documents

Web viewLa solución a nivel de base de datos Oracle debe operar bajo el ... Se debe entregar manual de contingencias que contenga una descripción de los procedimientos