CONTRATO DE COMPRAVENTA No. DE 2016
XXXXXXXX XX XXXXXXXXXXX Xx. XX 0000
CONTRATISTA: UNION TEMPORAL SUPERSALUD 2016
OBJETO Adquisición, licenciamiento y servicios conexos para la implementación del sistema de información para la Gestión Documental en la Superintendencia Nacional de Salud.
VALOR: MIL TRESCIENTOS CINCUENTA MILLONES DOSCIENTO CAURENTA MIL PESOS
($.1.350.240.000) M/CTE, incluido IVA, y todos los costos directos e indirectos, tasas y contribuciones que conlleve la celebración y ejecución total del contrato.
PLAZO: El plazo del presente contrato será el período comprendido desde la fecha de suscripción del acta de inicio y hasta doce (12) meses posteriores, previo perfeccionamiento del contrato, expedición del registro presupuestal y aprobación de la garantía única por parte de la Superintendencia.
Entre la SUPERINTENDENCIA NACIONAL DE SALUD, identificada con Nit. 860.062.187-4, representada por XXXXX XXXXXX XXXXXX XXXXXX, mayor de edad, vecina de esta ciudad, identificada con la cédula de ciudadanía No. 51.850.459, de Bogotá D.C., nombrada mediante Resolución No. 001220 del 28 xx Xxxxx de 2016, posesionada según Acta No. 000073 del 2 xx xxxx de 2016, facultada legalmente para adelantar todos los trámites relacionados con la actividad contractual, de conformidad con la Resolución No. 150 del 17 de enero de 2014, quien para efectos del presente contrato se denominará LA SUPERINTENDENCIA de una parte, y, la sociedad UNION TEMPORAL SUPERSALUD 2016 identificada con NIT. No 901.026.387-6, con domicilio en Bogotá D.C., representada legalmente por XXXXX XXXXXX XXXXX XXXXXX, también mayor de edad, identificado con la cédula de ciudadanía número 79.796.780 de Bogotá D.C., en calidad de Representante Legal de la Unión Temporal, conformado por las sociedades Project and Business Management S.A.S con Nit No. 900.505.014-6 y con el 65% de participación; y IO Innovation Place S.A.S con Nit No. 900.595.921-6 y con el 35 % de participación, quien bajo la gravedad de juramento afirma no encontrarse incurso en ninguna de las causales de inhabilidad e incompatibilidad o conflicto de interés a que se refieren los artículos 8o. y 9o. de la Ley 80 de 1993 y demás disposiciones vigentes sobre la materia y que para los efectos del presente documento se denominará EL CONTRATISTA, de común acuerdo hemos convenido celebrar el presente contrato, previas las siguientes CONSIDERACIONES: 1) Que de conformidad con lo dispuesto en la Ley 80 de 1993 y la Ley 1150 de 2007, junto con los Decretos Reglamentarios; en especial lo regulado en el Decreto 1082 de 2015 y demás normas concordantes, se elaboraron los Estudios Previos, el Pliego de Condiciones y el anexo técnico del proceso de Licitación Publica No.LP-32-2016, que tuvo por objeto: “Adquisición, licenciamiento y servicios conexos para la implementación del sistema de información para la Gestión Documental en la Superintendencia Nacional de Salud”. 2) Que, por la naturaleza del objeto a contratar, la modalidad de selección que correspondió a esta contratación fue una Licitación Pública de acuerdo con lo establecido en la Ley 80 de 1993, en concordancia con lo señalado en el numeral 1º del artículo 2º de la Ley 1150 de 2007, en lo dispuesto por en el artículo 2.2.1.2.1.1.2 del Decreto 1082 de 2015.y las demás normas concordantes y complementarias sobre la materia. 3) Que la Superintendencia Nacional de Salud publicó el 31 xx xxxxxx de 2016, los Estudios Previos, el Aviso de Convocatoria, el aviso de que trata el artículo 224 del Decreto 019 de 2012, el Proyecto xx Xxxxxx de Condiciones y el anexo técnico en el Sistema Electrónico para la Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx o xxx.xxxxxxxxx.xxx.xx, por el término xx xxxx (10) días hábiles, esto es desde el 1 al 14 de septiembre de 2016, con el propósito de suministrar a los interesados, la información necesaria para realizar
la sugerencias y observaciones, tendientes a unificar criterios en el contenido xxx Xxxxxx de Condiciones Definitivo.
4) Que para el proceso de Licitación Pública No.LP-32-2016, se asignó un presupuesto por la suma de hasta MIL TRESCIENTOS CINCUENTA Y OCHO MILLONES CIENTO SESENTA Y CUATRO MIL CUATROCIENTOS CINCUENTA Y SEIS PESOS ($1.358.164.456), M/CTE , incluido IVA y todos los costos directos e indirectos, tasas y contribuciones que conlleve la celebración y ejecución total del contrato que resulte del presente proceso de selección.5) Que LA SUPERINTENDENCIA cuenta con los recursos disponibles para atender los servicios de la presente contratación según consta en el Certificado de Disponibilidad Presupuestal No 20116 del 20 xx xxxxx de 2016 y aprobación de vigencias futuras No. 35716 del 12 xx xxxxxx de 2016 expedida por la Coordinador del Grupo de Presupuesto de la Secretaria General de la Superintendencia Nacional de Salud. 6) Que mediante Resolución No. 2914 del 27 de septiembre 2016 del 17 se ordenó la apertura del Proceso de Licitación Pública No. LP-32-2016, acto que fue publicado en la misma oportunidad en el Sistema Electrónico para la Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx ó xxx.xxxxxxxxx.xxx.xx, junto con los Estudios Previos Definitivos, el Pliego de Condiciones Definitivo y el Anexo técnico”. 7) Que el 29 de septiembre de 2016, se realizó la Audiencia de Aclaraciones y Asignación de Riesgos de la Licitación Pública No.LP-32-2016, de la cual se levantó el acta correspondiente y el Consolidado de Respuestas a las Observaciones formuladas en la audiencia, publicada el 04 de octubre de 2016 en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxx.xxx.xx o xxx.xxxxxxxxxxxxxx.xxx.xx. 8) Que el día 04 de octubre de 2016 se expidió la Adenda No 1 publicado en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx o xxx.xxxxxxxxx.xxx.xx. 9) Que durante el término de publicación xxx Xxxxxx de Condiciones Definitivo, presentó observación las firmas IO Inovatión Place, Bextechnology S.A, Nexura International, Total Quality Management, Sertisoft SAS, Stefanini Informática &Tecnología, a las cuales se le dio respuesta y se expidió Adenda No. 2 modificando: i) La nota 6 del numeral
4.3.1 “Experiencia” ii) el numeral 4.3.2 “Equipo mínimo de trabajo”. iii) El numeral 10 del Anexo Técnico” Equipo Mínimo requerido para el proyecto” y iv) el Literal B) “Equipo Mínimo de trabajo” del formato 2 xxx Xxxxxx de Condiciones Definitivo. Dichos documentos fueron publicados los días 4 y 6 de octubre de 2016, en el Sistema Electrónico para la Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx o xxx.xxxxxxxxx.xxx.xx. 10) Que el día 06 de octubre de 2016 se expidió la Adenda No 2 publicado en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx o xxx.xxxxxxxxx.xxx.xx. 11) Que el doce (12) de octubre de 2016 a las 10:00 A.M. se efectuó el cierre del proceso y la apertura de las propuestas, en la cual presentó oferta el siguiente proponente: Unión Temporal Supersalud 2016. 12) Que el día 24 de octubre de 2016 se expidió la Adenda No 3 publicado en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxxxxxxx.xxx.xx o xxx.xxxxxxxxx.xxx.xx. 13) Que el 25 de octubre de 2016 se publicó en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxx.xxx.xx, xxx.xxxxxxxxxxxxxx.xxx.xx, el Informe de Verificación Preliminar de Requisitos Habitantes, en cumplimiento de lo establecido en el numeral 4 del artículo 2.2.1.2.1.2.20 del Decreto 1082 de 2015. 14) Que el día 03 de noviembre de 2016 se publicó el Informe Definitivo de Verificación y Evaluación en el Sistema Electrónico para la Contratación Pública xxx.xxxxxxxxx.xxx.xx ó xxx.xxxxxxxxxxxxxx.xxx.xx. 15) Que el comité evaluador con base en el resultado de la verificación de los requisitos habilitantes y de los factores de selección y ponderación, RECOMENDÓ al ordenador adjudicar el proceso de selección LP- 32- 2016 a la UNIÓN TEMPORAL SUPERSALUD 2016. 16) Que el 08 de noviembre de 2016 se llevó a cabo la Audiencia Pública de adjudicación, en la cual se verificó la asistencia del proponente, se dio lectura a las reglas de la audiencia y posteriormente se dio la palabra al proponente y posteriormente la Secretaria General acogió la recomendación del Comité Evaluador y procedió adjudicar el contrato resultante del proceso de Licitación Pública No. LP-32-2016, mediante la Resolución No. 003296 de la misma fecha a la propuesta presentada por la Unión Temporal Supersalud 2016, por un valor total de hasta $1.350.240.000.oo incluido IVA y todos los impuestos, costos directos e indirectos a los que haya lugar; documento que fue publicado el 08 de noviembre de 2016 en el Sistema Electrónico de Contratación Pública xxx.xxxxxxxxx.xxx.xx, xxx.xxxxxxxxxxxxxx.xxx.xx. Por lo tanto, ACORDAMOS:
CLÁUSULA PRIMERA. - OBJETO: Adquisición, licenciamiento y servicios conexos para la implementación del sistema de información para la Gestión Documental en la Superintendencia Nacional de Salud.
CLÁUSULA SEGUNDA. - OBLIGACIONES DEL CONTRATISTA: En virtud del presente contrato, EL CONTRATISTA tiene las siguientes obligaciones:
I. GENERALES: 1. El proponente adjudicatario dentro de los dos (2) días hábiles siguientes a la adjudicación del presente proceso, deberá presentar para revisión y aprobación por parte de la SUPERINTENDENCIA NACIONAL DE SALUD, los documentos soporte exigidos para el equipo mínimo requerido, de los demás integrantes que no fueron incluidos en la presentación de la propuesta. 2. Presentar durante los dos (2) días hábiles siguientes a partir de la firma del contrato, en el Grupo de Contratación de Bienes y Servicios de la SUPERINTENDENCIA, la garantía única, conforme a los amparos exigidos en el contrato. 3.Realizar de forma cumplida y acreditar el pago de aportes al Sistema de Seguridad Social Integral y Parafiscales presentando los documentos respectivos que así lo acrediten, de conformidad con lo establecido en la Ley 1150 de 2007 y su normatividad regente. 4. Ejecutar con plena autonomía técnica y administrativa el objeto contractual. Sin perjuicio de esta autonomía, atenderá las recomendaciones y lineamientos que durante el desarrollo del contrato se le impartan por parte del Supervisor. 5. Comprometerse en el desarrollo del objeto del contrato a realizar su mejor esfuerzo utilizando al máximo sus conocimientos, habilidades y experiencia. 6. Realizar las labores contratadas en forma independiente, bajo su propio riesgo y responsabilidad, con sujeción a condiciones que requieran para el cumplimiento del objeto contractual y sin que ello implique exclusividad. 7. Guardar reserva, respecto a la información a la que se tenga acceso con ocasión del contrato y no utilizarla sino exclusivamente en relación con los fines del mismo. 8. Suscribir simultáneamente a la firma del contrato el acuerdo de confidencialidad y reserva de manejo de la información que suministre la Superintendencia Nacional de Salud. 9. Obrar con lealtad y buena fe durante la ejecución del contrato, evitando dilaciones injustificadas o acceder a peticiones o amenazas de quienes actúen por fuera de la Ley, con el fin de obligarlos a hacer u omitir algún acto o hecho, debiendo informar inmediatamente al de la SUPERINTENDENCIA, y a las demás autoridades competentes, para que adopten las medidas y correctivos que fueren necesarios. 10. Responder por el cuidado y custodia de la información, documentos y demás que le sean entregados, suministrados o remitida por parte de la Superintendencia Nacional de Salud. 11. Reportar cualquier novedad o anomalía, inmediatamente que se haya presentado o se estime sucederá y pueda afectar la ejecución del contrato al encargado de la Supervisión del mismo.12. Responder ante terceros por los daños que se ocasionen y que provengan de causas que le sean imputables. 13.Dar cumplimiento a los lineamientos y políticas del sistema integrado de gestión de calidad de la Superintendencia Nacional de Salud publicado en la página web y al cual tendrá acceso a nivel de detalle durante la ejecución del contrato. 14. Suscribir o presentar los documentos contractuales necesarios para la ejecución del contrato y el acta de liquidación del mismo.
II. ESPECÍFICAS:
1. Cumplir a cabalidad el objeto y las obligaciones del contrato teniendo en cuenta las especificaciones técnicas mínimas establecidas en el Anexo No. 1 “Especificaciones Técnicas Mínimas” xxx xxxxxx de condiciones, la propuesta y el contrato. 2. Planear y desarrollar la ejecución del contrato dando cumplimiento al cronograma de alto nivel descrito en el anexo técnico numeral 12. 3. Entregar el documento denominado “Plan de Proyecto” dentro del primer mes de ejecución del contrato para aprobación del Supervisor Técnico, el cual debe realizarse bajo el marco de referencia de PMBOK y contener todos los capítulos sugeridos en el mencionado marco de referencia, incluyendo dentro de este el Plan de Gestión de asimilación del Cambio. Este documento debe ser actualizado y detallado de acuerdo con el levantamiento de información y definiciones del Supervisor Técnico y Funcional durante la
ejecución del contrato. 4. Realizar una presentación del producto ofertado quince (15) días calendario y posteriores a la firma del acta de inicio para efectos de verificación del cumplimiento de los requisitos funcionales descritos en los capítulos 1.4 Alcance del Contrato y 3. Requerimientos Funcionales del Anexo de Especificaciones Técnicas Mínimas. 5. Dar cumplimiento al cronograma y plan de trabajo aprobado por la entidad; en caso de requerir modificaciones al mismo, estás deberán ser aprobadas por los supervisores del contrato y documentadas por el contratista en el plan de proyecto de acuerdo con la aprobación recibida. 6. Entregar todas las licencias solicitadas, necesarias y suficientes para poner en producción el sistema de información contratado teniendo en cuenta los requerimientos descritos en el Anexo No. 1 “Especificaciones Técnicas Mínimas” y que garanticen el uso del sistema de información a todos los usuarios requeridos. Las licencias deben entregarse con derechos de uso a perpetuidad a nombre de la Superintendencia Nacional de Salud, incluyendo tres (3) años de servicio de soporte y garantía. 7. Entregar junto con las licencias los siguientes documentos: i. Documentos que certifican el derecho de uso del software objeto del presente contrato, a nombre de la Superintendencia Nacional de Salud, ii. Medios de instalación y configuración, iii. Código fuente y derechos de autor de todos los componentes independientes, la personalización de la solución, el reporteador y el porcentaje de desarrollo realizado,
iv. Manuales actualizados (técnicos y de usuario final) que correspondan a la versión del software instalado y de acuerdo con lo descrito en el Anexo No. 1 “Especificaciones Técnicas Mínimas”, numeral 13, v. Documento suscrito por el Representante Legal del contratista donde conste el derecho de la Superintendencia de acceder a los servicios que se describen a continuación, durante los doce (12) meses contados a partir del recibo a satisfacción de cada una las licencias y sistema de información instalados en producción: a. Soporte Técnico y Garantía: Atención a fallos y errores del software y prestar servicios profesionales de acompañamiento a los procesos, dando cumplimiento a los ANS -Acuerdo de Niveles de servicio acorde con lo descrito en el Anexo No 1 “Especificaciones Técnicas Mínimas”. b. Actualización de la licencia cuando exista una nueva versión en el mercado durante el tiempo de soporte contratado. 8. Cumplir con las políticas y los lineamientos del manual de identidad visual de la Oficina Asesora de Comunicaciones Estratégicas e Imagen Institucional de la Supersalud, para todos los diseños incluidos en el sistema de información e interfaz gráfica de usuario – GUI, implementados, así mismo dar cumplimiento a las políticas internas de la entidad asociada a la seguridad de la información y seguridad informática y dar cumplimento a los requisitos del anexo técnico asociados al componente de seguridad. 9. Suministrar durante la puesta en producción del sistema de información las claves de instalación de las licencias contratadas.10. Informar con mínimo cuatro (4) meses de antelación a la instalación y configuración, los requerimientos de infraestructura requeridos por el contrato para el correcto funcionamiento del sistema de información y que no sean obligación del contratista proveer. 11. Realizar la instalación y configuración de las licencias adquiridas en los servidores que el Supervisor Técnico indique para tal fin, garantizando el adecuado funcionamiento de las mismas. 12. Dar cumplimiento a los requerimientos y principios relacionados con la Arquitectura de Referencia definida por la Oficina de Tecnologías de la Información de la Supersalud, en relación con los componentes Arquitectónicos transversales al sistema de información, los cuales hacen parte de los requerimientos mínimos del Anexo No. 1 “Especificaciones Técnicas Mínimas”. 13. Apoyar la validación de los procesos y procedimientos funcionales existentes en el Sistema Integrado de Gestión. 14. Disponer de una bolsa de 1000 horas durante la ejecución del contrato y los periodos de soporte y garantía para la implementación de nuevas funcionalidades que se generen posteriormente a lo definido en la etapa de Ingeniería de Requerimientos y hayan surtido el proceso de Control de Cambios definido por la Supersalud. Para el efecto, el contratista deberá tener presente que el
uso de las 600 horas se hará una vez agotadas las ofertadas (400 horas). 15. Realizar las actividades de cargue y/o migración que sean requeridas para el poblamiento de datos del sistema de información a implementar y acorde con lo descrito en el Anexo No. 1 “Especificaciones Técnicas Mínimas”.16. Realizar las actividades de gestión de cambio para la implementación del sistema de información de acuerdo con lo definido en el plan de proyecto que atienda las solicitudes de los supervisores, con el fin de lograr apropiación del sistema de información por parte de los usuarios finales. 17. Ejecutar el contrato dando cumplimiento a los Acuerdos de Niveles de Servicios definidos en el Anexo No 1 “Especificaciones Técnicas Mínimas”, así como entregar el reporte mensual de los datos necesarios para el cálculo del cumplimiento de los ANS. Lo anterior será el insumo para la validación de los pagos en los periodos correspondientes. 18. Realizar la transferencia de conocimiento descrita en el Anexo No 1 “Especificaciones Técnicas Mínimas”, para usuarios finales y administradores del sistema de información, incluyendo todos los temas técnicos que involucre el producto contratado, durante la ejecución del contrato, de conformidad con el Plan de Proyecto aprobado por los Supervisores Técnico y Funcional. 19. Realizar las jornadas de capacitación de INGENIERÍA DE REQUERIMIENTOS, de acuerdo con las condiciones descritas en el Anexo No. 1 “Especificaciones Técnicas Mínimas”, durante la ejecución del contrato, de conformidad con la programación acordada con el Supervisor Técnico y Funcional. 20. Prestar el acompañamiento en sitio para la estabilización de los sistemas de información durante un tiempo mínimo de seis (6) meses, después del despliegue de la solución. 21. Informar y coordinar con la Superintendencia Nacional de Salud, la instalación de nuevas versiones de las licencias adquiridas que sean liberadas por el fabricante, durante los tres (3) años de soporte y garantía, previa concertación con la Oficina de Tecnologías de la Información de la Supersalud. 22. Implementar las treinta y dos (32) API´S o interfaces de aplicación que fueron ofertadas en la propuesta. 23. Dar respuesta a los requerimientos de los Supervisores Técnico y Funcional definidos para el contrato, en un plazo no mayor a dos (2) días hábiles después de haber recibido la solicitud. 24. Dar solución a los requerimientos de los Supervisores Técnico y Funcional definidos para el contrato en el plazo que para tal efecto se acuerde entre las partes o dentro de los niveles de ANS definidos. 25. Realizar, participar y documentar mediante actas todas las reuniones de seguimiento y/o actividades necesarias para el cumplimiento del objeto contractual, y gestionar el trámite administrativo para la debida aprobación de las mismas, acorde con el proceso interno de la Supersalud. 26. Garantizar que los integrantes del equipo mínimo de trabajo descrito en el Anexo No. 1 “Especificaciones Técnicas Mínimas” correspondan al personal requerido, sin perjuicio que el mismo pueda ser modificado a solicitud del contratista, siempre que cumpla con el mismo perfil exigido y ofrecido en su propuesta, previa aprobación del Supervisor Técnico del contrato, y en los casos de fuerza mayor o caso fortuito, debidamente comprobados. 27. Garantizar durante la ejecución del contrato el cambio de personal por solicitud debidamente justificada del Supervisor Técnico del contrato, en los siguientes eventos: a) Cuando el desarrollo de sus actividades no sea satisfactoria, o sus actuaciones atenten contra la buena relación con el contratante o el equipo de trabajo, o cause algún impacto negativo a la Entidad. b) Por fuerza mayor o caso fortuito debidamente comprobados. c) En caso de enfermedad o vacaciones será reemplazado y solo por el tiempo necesario. En el caso de estos eventos el contratista deberá sustituir al profesional, en un periodo que no exceda una semana, por otro que reúna, como mínimo, los requisitos de formación académica y experiencia profesional de la persona que será remplazada; igualmente deberá garantizar que ello no impactará ni pondrá en riesgo el proyecto. El Contratista deberá plantear acciones tendientes a recuperar los tiempos, sin que esto se haga x xxxxx del esfuerzo de la Supersalud y asumirá los costos de incurrir en mayores tiempos de ejecución. 28. Garantizar que todo el personal del contratista
que preste sus servicios para la ejecución del contrato se encuentre vinculado contractualmente con este y afiliado al Sistema de Seguridad Social Integral de acuerdo con la normatividad vigente que regule la materia. 29. Informar al Supervisor del contrato en un plazo máximo de tres (3) días contados a partir de la ocurrencia de hechos, sobre las imposibilidades o dificultades que se presenten en la ejecución del mismo, proponiendo alternativas de solución o mitigación de la problemática informada. 30. Hacer entrega de la documentación necesaria para el proceso de ingreso al almacén de los bienes o productos objeto del contrato. 31. Entregar los informes y soportes solicitados por los supervisores para efectos de recibo de productos y trámites de pagos correspondientes al contrato. 32. Entrega de mínimo dos (2) informes mensuales con corte quincenal, de seguimiento al proyecto de acuerdo con lo descrito al plan de proyecto aprobado por los supervisores del contrato. 33. El contratista deberá considerar, todos los elementos, servicios y componentes inherentes que requiere para operar de forma correcta el sistema de información para la Gestión Documental de la Superintendencia Nacional de Salud, de acuerdo con las condiciones descritas en el Anexo No. 1 “Especificaciones Técnicas Mínimas”. 34. Las demás que sean necesarias para dar cumplimiento al objeto contractual y que se hayan indicado en la propuesta presentada por el contratista.
CLÁUSULA TERCERA. - OBLIGACIONES DE LA SUPERINTENDENCIA: En virtud del presente
contrato, LA SUPERINTENDENCIA tiene a cargo las siguientes obligaciones: Expedir el registro presupuestal. 1. Expedir el registro presupuestal. 2. Aprobar la póliza que garantiza el contrato. 3. Suscribir el acta de inicio. 4. Proporcionar la información y recursos necesarios para la debida y oportuna ejecución del contrato. 5. Proporcionar los medios suficientes y necesarios de acuerdo con el plan del proyecto para el acceso a la información que será migrada al nuevo sistema de información. 6. Disponer de los recursos humanos necesarios durante la ejecución del contrato y especialmente para desarrollar las Etapas de Análisis, Diseño, Migración, Pruebas y Estabilización. 7. Proveer los profesionales idóneos con conocimiento y experticia necesaria que participen desde las etapas de construcción hasta la entrega de los productos contratados de acuerdo con la tecnología a implementar. 8. Disponer del espacio físico necesario durante la ejecución del contrato. 9. Comunicar al contratista por escrito con la debida oportunidad las observaciones sobre la ejecución del contrato. 10. Adelantar a través del supervisor los trámites necesarios para realizar el ingreso al almacén de los bienes objeto de este contrato. 11. Realizar los pagos previa presentación correcta por parte del contratista, de los documentos requeridos y acorde con los plazos establecidos por la Superintendencia Nacional de Salud. 12. Aprobar a través del supervisor técnico y el supervisor funcional, los productos contratados de acuerdo con el plan de trabajo definido:
CLÁUSULA CUARTA. - PLAZO DE EJECUCIÓN: El plazo de ejecución del contrato será el período comprendido desde la fecha de suscripción del acta de inicio y hasta doce (12) meses posteriores, previo perfeccionamiento del contrato, expedición del registro presupuestal y aprobación de la garantía única por parte de la Superintendencia. La ejecución se realizará de la siguiente forma: Vigencia 2016: i) La Supersalud recibirá los entregables de las Fases de Inicio y Planeación y en la Vigencia 2017 ii) La Supersalud recibirá los entregables restantes contratados, dentro del tiempo acordado y aprobado en el cronograma del proyecto.
CLAÚSULA QUINTA. - VALOR DEL CONTRATO: El valor del presente contrato es por la suma de MIL TRESCIENTOS CINCUENTA MILLONES DOSCIENTOS CUARENTA MIL PESOS ($$1.350.240.000.oo), M/CTE
incluido XXX y todos los impuestos, costos directos e indirectos a los que haya lugar, discriminados de la siguiente manera.
VIGENCIA 2016: Hasta un valor de NOVENTA Y UN MILLONES SEISCIENTOS CUARENTA MIL PESOS M/CTE
($91.640.000), INCLUIDO IVA, y todos los costos directos e indirectos, tasas y contribuciones a que haya lugar.
VIGENCIA 2017: Hasta un valor de MIL DOSCIENTOS CINCUENTA Y OCHO MILLONES SEIS CIENTOS MIL
PESOS M/CTE ($1.258.600.000). INCLUIDO IVA y todos los costos directos e indirectos, tasas y contribuciones a que haya lugar.
CLAUSULA SEXTA. - SUJECIÓN DEL PAGO A LAS APROPIACIONES PRESUPUESTALES: El valor monetario
que LA SUPERINTENDENCIA se compromete a pagar por el presente contrato con el certificado de disponibilidad presupuestal No. 20116 del 20 xx xxxxx de 2016 y apropiación de vigencias futuras No. 35716 del 12 xx xxxxxx de 2016 expedida por la Coordinadora del Grupo de Presupuesto de la Subdirección Financiera de la Superintendencia Nacional de Salud.
PARÁGRAFO. El Grupo de Presupuesto procederá a liberar la diferencia entre el valor del Certificado de Disponibilidad y el Valor del Registro Presupuestal que se expedirá como requisito de ejecución en el presente contrato.
CLAUSULA SEPTIMA. - FORMA DE PAGO: La Superintendencia Nacional de Salud pagará el valor del Contrato al recibir los entregables agrupados por hitos, descritos en la siguiente tabla y conforme a las especificaciones del Anexo No. 1, Especificaciones Técnica Mínimas, Numeral 13 y cronograma propuesto por el proponente dentro del plazo establecido, de la siguiente forma:
Vigencia 2016:
HITO VIGENCIA 2016 | FASE | SUBFASE | ID Entregable | ENTREGABLE | CANTIDAD | PAGO |
1 | INICIO | INICIO | 1 | Acta de elaboración del Kick OFF del proyecto | 1 | $91.640.000 |
2 | Documento del Project Charter | 1 | ||||
PLANEACIÓN | PLANEACIÓN | 3 | Documento del Plan del proyecto | 1 | ||
4 | Plan detallado para asimilación del cambio | 1 | ||||
5 | Plan detallado para Transferencia de conocimiento | 1 | ||||
6 | Documento de validación del producto contratado en relación con el cumplimiento de los requerimientos funcionales y no funcionales | 1 |
Vigencia 2017
HITO VIGENCIA 2017 | FASE | SUBFASE | ID Entregable | ENTREGABLE | CANTIDAD | PAGO |
2 | EJECUCIÓN | ANÁLISIS | 7 | Informe de aprobación de Especificación detallada de requerimientos | 1 | $270.280.000 |
HITO VIGENCIA 2017 | FASE | SUBFASE | ID Entregable | ENTREGABLE | CANTIDAD | PAGO |
8 | Documento de Análisis de Requerimientos Funcionales, no Funcionales y de migración | 1 | ||||
9 | Certificación del ambiente de Pruebas y Desarrollo del Contratista | 1 | ||||
DISEÑO | 10 | Documento que contenga el Árbol funcional de implementación de requerimientos | 1 | |||
11 | Informe de resultados aprobación prototipos acordados | 1 | ||||
12 | Documento - Guías de configuración de la aplicación | |||||
13 | Diseño de los desarrollos a la medida para los componentes de Citaciones y Notificaciones, servicios web, reportes, mecanismos de firmas y los demás que se requieran para la solución | 1 | ||||
14 | Diseño funcional de las aplicaciones y Diseño de los lineamientos gráficos y experiencia del usuario | 1 | ||||
15 | Diseño del sistema de información | 1 | ||||
16 | Documento que contenga la estrategia de: i) migración de datos históricos y poblamientos de tablas y ii) Plan de Pruebas parciales e integrales de acuerdo con el cronograma establecido para las fases. | 2 | ||||
17 | Plan de capacitación formal y listas de asistencia que evidencien la realización de cursos de capacitación formal. | 1 | ||||
3 | DESARROLLO | 18 | Informe de avance mensual de desarrollos | 1 | $407.160.000 | |
19 | Acta de entrega de la aplicación para Sub-fase de pruebas | 1 | ||||
20 | Guion que contenga los casos de prueba funcionales y no funcionales | 1 | ||||
21 | Informe Pruebas Unitarias | 1 | ||||
PRUEBAS | 22 | Informe de Migración de datos históricos y poblamientos de tablas | 1 | |||
23 | Informe de Resultados de la Ejecución de Pruebas Integrales del sistema | 1 | ||||
24 | Manual funcional | 1 | ||||
25 | Manual técnico | 1 | ||||
26 | Documento del Plan de salida en vivo | 1 | ||||
27 | Informe del inicio del despliegue de los productos aprobados por los supervisores y de acuerdo con el plan detallado del proyecto. | 1 | ||||
4 | DESPLIEGUE | 28 | Documentos de titularidad de las licencias de la aplicación y componentes adicionales a nombre de la Superintendencia Nacional de Salud. | 1 | $271.440.000 | |
29 | Informe de transferencia de conocimiento a usuarios finales y administradores técnicos y funcionales. | 1 | ||||
30 | Certificación del ambiente de producción | 1 | ||||
31 | Acta que evidencie la Instalación o despliegue de software base y de solución | 1 |
L02
COF Página 8 de 91
HITO VIGENCIA 2017 | FASE | SUBFASE | ID Entregable | ENTREGABLE | CANTIDAD | PAGO |
32 | Informe de poblamiento de tablas básicas y parámetros | 1 | ||||
33 | Informe de resultados exitosos de la salida en vivo total del sistema de información. | 1 | ||||
5 | ESTABILIZACIÓN | 34 | Informe de Mejoras efectuadas durante el Servicio de acompañamiento para la estabilización del sistema de información | 1 | $176.320.000 | |
MONITOREO Y CONTROL | 35 | Informe Mensual de avance del proyecto para el comité directivo | 1 | |||
6 | CIERRE | CIERRE | 36 | Medios de instalación de la aplicación, con la última personalización aprobada y puesta en producción y la documentación en última versión. | 1 | $133.400.000 |
37 | Informe de recibo a satisfacción de las funcionalidades puestas en producción por consumo de la bolsa de horas | 1 | ||||
38 | Informe final de cierre | 1 |
PARAGRAFO PRIMERO: Los pagos serán realizados por hitos de acuerdo como se relacionan en este numeral y están sujetos al cumplimiento de los entregables asignados y recibidos a satisfacción por la Supersalud.
PARAGRAFO SEGUNDO: El valor de pago de cada hito, estará sujeto a la entrega y al cumplimiento de Acuerdos de Niveles de Servicios, descritos en el Anexo No. 1 “Especificaciones Técnicas Mínimas”.
PARAGRAFO TERCERO: Para efectos del pago, EL CONTRATISTA deberá presentar: a.) Factura o documentos equivalente de conformidad con la Ley. b.) Certificación de los Supervisores Técnico y/o Funcionales según corresponda, acorde con lo establecido en el numeral 13 “Entregables” del Anexo No. 1 “Especificaciones Técnicas Mínimas”, en la que conste la verificación de cumplimiento del objeto y de las obligaciones, así como de los aportes de conformidad con el artículo 50 de la Ley 789 de 2002 y demás normas concordantes. c.) Certificación expedida por el Revisor Fiscal o representante legal sobre el cumplimiento de los pagos al Sistema de Seguridad Social, cajas de compensación y demás de acuerdo con el artículo 50 de la Ley 789 de 2002 y normas concordantes.
PARAGRAFO CUARTO: La forma de pago prevista, está sujeta a la situación de los recursos por parte del Ministerio de Hacienda y Crédito Público una vez se encuentre aprobado el PAC (Programa Anual de Caja) y dentro de los 30 días siguientes a la presentación de los documentos requeridos para el efecto. Los pagos se realizarán mediante abono en cuenta.
El valor del último pago estará sujeto a la firma del acta de liquidación.
PARAGRAFO QUINTO: El pago que deberá realizar LA SUPERINTENDENCIA de conformidad con la presente cláusula, será efectuado en la cuenta de ahorros No.476770005165 del Banco Davivieda, según certificación bancaria aportada por Project and Business Management SAS.
CLÁUSULA OCTAVA. - LUGAR DE EJECUCIÓN: El lugar de ejecución del contrato será la ciudad de Bogotá, en
Sede Principal de la Superintendencia Nacional de Salud en la ciudad de Bogotá D.C.
CLÁUSULA NOVENA. - GARANTÍAS: EL CONTRATISTA garantizará el cumplimiento de las obligaciones que adquiere por el presente contrato, mediante la constitución de una Garantía Única a favor de LA SUPERINTENDENCIA, en una compañía de seguros legalmente establecida en Colombia, cuya póliza se encuentre debidamente aprobada por la Superintendencia Financiera de Colombia con los anexos especiales para entidades oficiales que aprobará LA SUPERINTENDENCIA, si reúne los requisitos legales y contractuales establecidos para tal fin la cual cubrirá los siguientes riesgos: a) Cumplimiento: Equivalente al veinte por ciento (20%) del valor del contrato, vigente por el término de duración del contrato y seis (6) meses más, contados a partir de la expedición de la Garantía Única. Cubrirá los perjuicios derivados de: i. Incumplimiento total o parcial del contrato, cuando el incumplimiento es imputable al contratista; ii. El cumplimiento tardío o defectuoso del contrato, cuando el incumplimiento es imputable al contratista. iii. El pago del valor de las multas y de la cláusula penal pecuniaria. b) Calidad y correcto funcionamiento de los bienes: Equivalente al treinta y cinco por ciento (35%) del valor total del Contrato, con una vigencia igual a la del Contrato y doce (12) meses más, contados a partir de la entrega y recibo a satisfacción de los bienes objeto del presente contrato. Esta garantía cubrirá a la Entidad de los perjuicios derivados imputables al contratista garantizando (i) mala calidad o deficiencias técnicas de los bienes por él suministrados, de acuerdo con las especificaciones técnicas establecidas en el contrato, o (ii) por el incumplimiento de los parámetros o normas técnicas establecidas para los bienes objeto del contrato. C). Calidad del servicio: Equivalente al veinticinco por ciento (25%) del valor del contrato, vigente por el término de doce (12) meses contados a partir de la fecha de terminación del contrato. Esta Garantía cubrirá a la Entidad de los perjuicios derivados de la deficiente calidad del servicio ocurridos con posterioridad a la terminación del contrato. D) Pago de Salarios y prestaciones Sociales e Indemnizaciones Laborales. Equivalente al cinco (5%) del valor total del contrato, vigente por el término de ejecución del contrato y tres (3) años mas contados a partir de la expedición de la garantía unica. Cubrirá los perjuicios ocasionados por incumplimiento de las obligaciones laborales del contratista derivadas de la contratación de personal para la ejecución del contrato amparado. E) Responsabilidad Civil Extracontractual. Equivalente a trescientos salarios mínimos mensuales legales vigentes (300 SMMLV), vigente por el término igual al de ejecución del contrato, contados a partir de la expedición de la Garantía Única. Esta Garantía cubrirá a la Entidad de eventuales reclamaciones de terceros derivadas de la responsabilidad extracontractual que surja de las actuaciones, hechos u omisiones de su contratista y de subcontratistas.
PARÁGRAFO PRIMERO: Las garantías establecidas en la presente cláusula debe constituirlas y presentarlas EL CONTRATISTA al Grupo de Contratación de Bienes y Servicios, a más tardar a los dos (2) días hábiles siguientes del perfeccionamiento del contrato, so pena de incurrir en incumplimiento de las obligaciones pactadas.
PARÁGRAFO SEGUNDO: EL CONTRATISTA deberá restablecer el valor de la garantía cuando éste se haya visto reducido por razón de las reclamaciones efectuadas por LA SUPERINTENDENCIA. De igual manera, en cualquier evento en que se adicione el valor del contrato o se prorrogue su término, EL CONTRATISTA deberá ampliar el valor de la garantía otorgada o ampliar su vigencia, según el caso.
CLAUSULA DÉCIMA. - SUPERVISIÓN: La Supervisión se realizará de manera conjunta, ejercida por el Jefe de Oficina de Tecnologías de la Información o quien haga sus veces, o por quien designe el Ordenador del Gasto mediante comunicación escrita; y el Coordinador del Grupo de Gestión Documental de la entidad, o quien haga sus veces o quien designe el Ordenador del Gasto mediante comunicación escrita. Los supervisores asumen la responsabilidad por el seguimiento y control del contrato, así como la correcta y cabal ejecución del mismo, de igual manera tendrán las obligaciones, responsabilidades y atribuciones de acuerdo con lo establecido en el artículo 53 de la Ley 80 de 1993 y sus Decretos Reglamentarios y el
Manual de Contratación de la Entidad.
CLÁUSULA DÉCIMA PRIMERA. - CESIÓN DEL CONTRATO: El presente contrato no podrá ser cedido por EL CONTRATISTA sin el consentimiento previo y por escrito de LA SUPERINTENDENCIA de conformidad con el inciso 3º del artículo 41 de la Ley 80 de 1993.
CLAUSULA DECIMA SEGUNDA. - AFILIACIÓN Y CUMPLIMIENTO DE LAS OBLIGACIONES CON EL SISTEMA
DE SEGURIDAD SOCIAL INTEGRAL Y PARAFISCALES: El CONTRATISTA manifiesta que está afiliado y al día en el pago de los aportes al Sistema de Seguridad Social Integral de todo su personal y aportes parafiscales.
CLAUSULA DECIMA TERCERA- EXCLUSION DE RELACION LABORAL: EL CONTRATISTA ejecutará el
presente contrato con sus propios medios y con autonomía técnica y administrativa. En consecuencia, no existirá vínculo laboral alguno entre la SUPERINTENDENCIA y EL CONTRATISTA.
CLÁUSULA DÉCIMA CUARTA. - FUERZA MAYOR O CASO FORTUITO: El CONTRATISTA estará exento de
responsabilidad o penalidad por atraso de las obligaciones del presente Contrato en caso de fuerza mayor o caso fortuito exenta de culpa que afecten la ejecución del mismo debidamente comprobado de conformidad con la Ley. El CONTRATISTA informará por escrito a la SUPERINTENDENCIA dentro de los tres (3) días hábiles siguientes a la ocurrencia. El plazo del Contrato se entenderá suspendido, previa suscripción de acta, mientras a juicio de la Entidad subsistan los efectos que originaron la fuerza mayor o caso fortuito.
CLÁUSULA DÉCIMA QUINTA. - SUSPENSION DEL CONTRATO: Las partes de común acuerdo o por circunstancias de fuerza mayor o caso fortuito, podrán suspender la ejecución del presente contrato, mediante la suscripción de un acta, en la cual se indique las razones de la suspensión y el término de duración de la misma, sin que el término de suspensión prorrogue el plazo de ejecución del contrato.
CLÁUSULA DÉCIMA SEXTA. - CONFIDENCIALIDAD: Con el fin de garantizar la no divulgación de información sensible a terceros, EL CONTRATISTA se obliga a guardar estricta reserva y confidencialidad de toda la información relacionada con la SUPERINTENDENCIA, de la cual tenga conocimiento por razón de las actividades que desarrolla.
CLÁUSULA DÉCIMA SEPTIMA. – RESPONSABILIDAD: EL CONTRATISTA responderá civil y penalmente tanto por el incumplimiento de las obligaciones derivadas del contrato, como por los hechos u omisiones que le fueren imputables y que causen daño o perjuicio a LA SUPERINTENDENCIA, todo de conformidad con lo dispuesto por los artículos 52, 53 y 56 de la Ley 80 de 1993.
CLÁUSULA DÉCIMA OCTAVA. - CAUSALES DE TERMINACIÓN DEL CONTRATO: Las partes podrán dar por
terminado el presente contrato por las siguientes causales: a. Terminación por Mutuo Acuerdo. b. Por incumplimiento en cualquiera de las obligaciones sin que medie justificación alguna. c. Por vencimiento del plazo de ejecución o hasta agotar el presupuesto. d. En los demás casos en los cuales no sea posible la ejecución del objeto contractual.
CLÁUSULA NOVENA. - SOLUCIÓN DIRECTA DE CONTROVERSIAS CONTRACTUALES: Las partes en aras de
buscar en forma ágil, rápida y directa las diferencias y discrepancias surgidas de la ejecución de este contrato, acudirán a los mecanismos de solución previstos en la Ley 80 de 1993, tales como la conciliación, amigable composición y transacción, sin perjuicio de lo previsto en la cláusula vigésima segunda y de las restantes facultades de la administración.
CLÁUSULA VIGESIMA - MULTAS: En caso xx xxxx o incumplimiento de las obligaciones de EL CONTRATISTA, LA SUPERINTENDENCIA podrá imponer a aquel mediante resolución motivada, multas diarias y sucesivas del uno por mil (1 X 1000) del valor del contrato, sin que exceda el diez por ciento (10%) del valor total del mismo o proporcional al incumplimiento según la gravedad del mismo a juicio de la Entidad, sin perjuicio de la declaración de caducidad. El pago o deducción de las multas no exonera al CONTRATISTA del cumplimiento de sus obligaciones emanadas del contrato. Las partes acuerdan que en caso de proceder a la aplicación de multas, la entidad lo podrá hacer directamente y el CONTRATISTA autoriza expresamente la realización del procedimiento y del descuento del valor de la multa de los saldos adeudados a la fecha en favor del CONTRATISTA.
CLÁUSULA VIGESIMA PRIMERA. - PENAL PECUNIARIA: El CONTRATISTA se obliga para con la
SUPERINTENDENCIA a pagar una suma equivalente al veinte (20%) del valor del contrato, a título de estimación anticipada de los perjuicios que llegara a sufrir en caso de declaratoria de caducidad o de incumplimiento total de las obligaciones que adquiere en el presente contrato, sin perjuicio que de manera proporcional se reduzca dicho valor en caso de un incumplimiento parcial.
PARÁGRAFO PRIMERO: En todo caso, en virtud del artículo 1600 del Código Civil, el valor de la cláusula penal pecuniaria que se haga efectiva, no se considerará como pago definitivo de los perjuicios causados, si se llegare a demostrar un perjuicio mayor al estimado en la presente cláusula.
PARAGRAFO SEGUNDO: El valor de la multa y de la cláusula penal pecuniaria se tomará del saldo a favor de EL CONTRATISTA si lo hubiere o de la garantía constituida. Si esto último no fuere posible se cobrará por jurisdicción coactiva.
CLÁUSULA VIGESIMA SEGUNDA. - PROCEDIMIENTO PARA IMPOSICIÓN DE MULTAS, CLAUSULA PENAL
PECUNIARIA, DECLARATORIA DE INCUMPLIMIENTO: Las partes dentro del libre ejercicio de la autonomía de su voluntad, establecen que para la aplicación de lo previsto en las cláusulas vigésima primera y vigésima segunda, se deberá seguir el procedimiento establecido en el artículo 86 de la Ley 1474 de 2011, de conformidad con lo siguiente: a) El Supervisor enviará al Ordenador del Gasto un informe escrito sobre los hechos constitutivos xx xxxx o de cualquier clase de incumplimiento. b) Una vez recibido el informe, el Ordenador del Gasto estudiará si tales hechos constituyen incumplimiento de las obligaciones del CONTRATISTA que ameriten la aplicación de las medidas previstas en el contrato o de cualquier otra medida contractual o legal. c) En el evento en que el Ordenador del Gasto o su delegado considere que los hechos descritos en los documentos aportados por el supervisor pueden constituirse en un retraso o incumplimiento de las obligaciones contractuales, citará al CONTRATISTA y a su garante a una audiencia, indicando claramente el lugar, fecha y hora para debatir lo ocurrido. Con la citación, se adjuntará copia del informe del supervisor en el cual debe estar mencionado en forma expresa y detallada, los hechos que soportan la solicitud de imposición de multa o incumplimiento, y enunciará las normas o cláusulas posiblemente violadas y las consecuencias que podrían derivarse para el CONTRATISTA. d) En desarrollo de la audiencia, el Ordenador del Gasto o su delegado, previa exposición de los hechos objeto de retraso o incumplimiento, concederá el uso de la palabra al representante legal del contratista o a quien lo represente, y posteriormente a su garante, para que presenten sus descargos, en desarrollo de lo cual podrá rendir las explicaciones del caso, aportar pruebas y controvertir las presentadas por el supervisor. e) Culminada esta etapa, el Ordenador del Gasto o su delegado podrá imponer o no la multa, sancionar o declarar el incumplimiento y hacer efectiva la cláusula penal pecuniaria, mediante resolución motivada. En el evento en que el incumplimiento sea catalogado como grave, se deberá declarar la caducidad del contrato. Contra la decisión que tome el Ordenador del Gasto o su delegado, sólo procederá recurso de reposición que se interpondrá, sustentará y se decidirá en la misma audiencia. La decisión sobre el recurso se entenderá notificada, en audiencia; f) En cualquier momento del desarrollo de la audiencia, el
Ordenador del Gasto o su delegado, podrá suspenderla, por el número de veces que sea necesario, de oficio o a petición de parte, para allegar o practicar pruebas que se estimen conducentes y pertinentes, o cuando por cualquier otra razón debidamente sustentada, se requiera para el correcto desarrollo de la actuación administrativa. En todo caso, al adoptar la decisión, se señalará fecha y hora para reanudar la audiencia.
PARAGRAFO: El Ordenador del Gasto o su delegado podrán dar por terminado el procedimiento en cualquier momento, si por algún medio tiene conocimiento de la cesación de la situación de incumplimiento, situación de la cual se levantará el acta correspondiente.
CLÁUSULA VIGESIMA TERCERA. - LIQUIDACIÓN: El presente contrato se liquidará de común acuerdo entre las partes, procedimiento que se realizará dentro de los cuatro (4) meses siguientes a su finalización, o a la fecha del acuerdo que lo disponga. La liquidación se efectuará mediante acta en la cual se describirán en forma detallada las actividades desarrolladas y/o recursos ejecutados. El acta de liquidación será suscrita por las partes, previo visto bueno del supervisor. En aquellos casos en que el CONTRATISTA no se presente a la liquidación previa notificación o convocatoria que le haga la entidad, o las partes no lleguen a un acuerdo sobre su contenido, la entidad tendrá la facultad de liquidar en forma unilateral dentro de los dos (2) meses siguientes, de conformidad con lo dispuesto en el artículo 11 de la Ley 1150 de 2007. Si vencido el plazo anteriormente establecido no se ha realizado la liquidación, la misma podrá ser realizada en cualquier tiempo dentro de los dos (2) años siguientes, de mutuo acuerdo o unilateralmente.
CLÁUSULA VIGÉSIMA CUARTA. - REGIMEN JURIDICO DEL CONTRATO: El presente contrato se rige en su celebración, ejecución, liquidación y demás efectos pertinentes por la Ley 80 de 1.993, la Ley 1150 de 2007 y sus decretos reglamentarios y las normas civiles, comerciales en los eventos no regulados por el Régimen de Contratación estatal.
CLÁUSULA VIGÉSIMA QUINTA. - GASTOS: Los gastos que se causen con motivo de la legalización de este contrato, serán por cuenta del CONTRATISTA.
CLÁUSULA VIGÉSIMA SEXTA. - REQUISITOS DE PERFECCIONAMIENTO Y EJECUCIÓN: El presente contrato
se perfecciona con la firma de las partes. Para el inicio de la ejecución del Contrato se requiere la suscripción del acta de inicio entre el CONTRATISTA y el Supervisor designado por la SUPERINTENDENCIA, previa expedición del registro presupuestal y aprobación de la garantía única por parte de la SUPERINTENDENCIA.
CLÁUSULA VIGÉSIMA SÉPTIMA. DOCUMENTOS. Hacen parte integral del presente contrato: 1. Los estudios previos; 2. El pliego de condiciones definitivo y sus adendas; 3. La propuesta del contratista; 4. Los demás documentos que se requieran en su desarrollo y ejecución.
CLÁUSULA VIGÉSIMA OCTAVA. DOMICILIO: El lugar de domicilio del presente contrato es la ciudad de Bogotá
D.C. Las partes aceptan todas y cada una de las condiciones aquí prevista y en constancia se firma por las partes en Bogotá, D.C. a los
Por LA SUPERINTEDENCIA, Por EL CONTRATISTA,
XXXXX XXXXXX XXXXXX XXXXXX | XXXXX XXXXXX XXXXX XXXXXX |
Xxxxxx y aprobó: Xxxxxxx Xxxxx Xxxxxxxx Xxxxxxx Proyectó: Xxxxxx Xxxxxxx
ANEXO N° 1 ESPECIFICACIONES TECNICAS
PROCESO No. OBJETO:
Oficina de Tecnologías de la Información Xxxxxx Xxxxxxx Soche
[Dirección de correo electrónico]
CONTENIDO
1. ASPECTOS GENERALES DEL ANEXO TÉCNICO 18
1.3 Modelo de Operación - Ciclo de vida de los documentos 19
1.3.1 Bosquejo funcional de los módulos para el sistema de gestión documental y correspondencia. 21
2. DEFINICIÓN DE ALCANCE DEL TRABAJO Y EDT (Estructura desagregada del trabajo) 23
3. REQUERIMIENTOS FUNCIONALES 24
3.1.1 Pantalla principal de la aplicación 25
3.1.2 Módulo de Administración 25
3.1.2.1 Configuración y parametrización 25
3.1.2.1.1 Tablas de retención documental 27
3.1.2.3 Seguridad Funcional 29
3.1.2.4 Búsqueda, recuperación y presentación 30
3.1.3 Módulo de Correspondencia 30
3.1.3.1 Radicado de Entrada 30
3.1.3.2 Captura de documentos digitalizados 31
3.1.4 Módulo de Centro de Gestión 31
3.1.5.1 Flujo de documentos internos 32
3.1.5.2 Envíos de radicados de salida físicos 33
3.1.5.3 Comunicados internos electrónicos 33
3.1.5.4 Radicados de salida físicos 34
3.1.6 Módulo Expediente SGDE 34
3.1.6.1 Creación de Expediente 34
3.1.6.2 Gestión de Expediente 35
3.1.6.3 Expedientes híbridos 36
3.1.6.4 Módulo de Auditoría Funcional 36
3.1.7.1 Transferencias documentales - SGDEA 37
3.1.7.2 Conservación de expediente en Archivo Central - SGDEA 38
3.1.7.3 Eliminación de expediente 38
3.1.9.1.1 USUARIOS GRUPO(S) DE NOTIFICACIONES – Envío comunicación y/o citación para notificación personal (física) 41
3.1.9.2 Gestión y trámite de Notificaciones 42
3.1.9.2.1 USUARIOS GRUPO(S) DE NOTIFICACIONES – Hacer citación personal 43
3.1.9.2.2 USUARIOS GRUPO(S) DE NOTIFICACIONES – Notificación por Edicto 43
3.1.9.2.3 USUARIOS GRUPO(S) DE NOTIFICACIONES – Hacer Notificación por Aviso Correo Físico 43
3.1.9.2.4 USUARIOS GRUPO(S) DE NOTIFICACIONES – Expedición Certificación de Firmeza 44
3.1.9.2.5 Usuarios grupo de Correspondencia 44
3.1.9.2.6 OTROS REQUERIMIENTOS DE NOTIFICACIONES 45
4. REQUERIMIENTOS NO FUNCIONALES (TÉCNICOS) 45
4.1 REQUERIMIENTOS TÉCNICOS GENERALES 46
4.7 REQUERIMIENTOS TÉCNICOS ADICIONALES A LA GESTIÓN DOCUMENTAL 56
4.8 DE LOS COMPONENTES ARQUITECTÓNICOS 56
4.8.1 Seguridad, auditoría y control de acceso 57
4.8.3 Consultas y visualización 58
4.8.5 Gestor de Contenido empresarial (ECM) 58
4.8.8 Administración de la configuración 59
6. TRANSFERENCIA DE CONOCIMIENTO PARA EL USO Y ADMINISTRACIÓN DE LOS PRODUCTOS 64
9. GESTIÓN DE ASIMILACIÓN DEL CAMBIO 67
10. EQUIPO MÍNIMO REQUERIDO PARA EL PROYECTO 69
11. CRONOGRAMA DE ALTO NIVEL DEL PROYECTO 73
12. HITOS PRINCIPALES DE PAGO Y DEL CRONOGRAMA 74
14. ACUERDOS DE NIVELES DE SERVICIO 82
14.1 Oportunidad y calidad en los entregables 83
14.2 Calidad en el funcionamiento del producto software en Sub-fase de pruebas de aceptación. 84
14.3 Calidad en el funcionamiento del producto software en Despliegue y estabilización: 85
1. ASPECTOS GENERALES DEL ANEXO TÉCNICO
Este documento es el resultado de un trabajo de visión de arquitectura empresarial, que presenta las generalidades de lo que involucra el alcance a contratar, cabe aclarar, que no llega a ser una especificación detallada, pues se considera que dentro del alcance del contrato, el contratista, realice el levantamiento de información y desarrolle un trabajo de ingeniería de requerimientos, hasta llegar a la interpretación de las necesidades a nivel xx xxxxxx, formatos, estándares de imagen, reglas de negocio entre otros.
1.1 Objetivo General
Contratar la adquisición del licenciamiento y los servicios para la implementación de un sistema de gestión documental y de correspondencia para la Superintendencia Nacional de Salud, que asegure los procesos de la gestión documental en su ciclo de vida, de acuerdo a las normas legales vigentes.
1.2 Objetivos Específicos
1. Adquirir el software de gestión documental para la Superintendencia Nacional de Salud. Se aclara que el esquema de arrendamiento de licencias no está considerado dentro de la presente contratación teniendo en cuenta que uno de los objetivos de la plataforma tecnológica de la entidad considera disponer de un licenciamiento a perpetuidad orientado a garantizar la continuidad del servicio.
2. Implementar en los servidores de la Superintendencia Nacional de Salud el software de gestión documental.
3. Parametrizar el software de gestión documental con las TRD de la Superintendencia Nacional de Salud, y demás funciones que garanticen el correcto funcionamiento del SGDE-A.
4. Diseñar y ejecutar la gestión de cambio para la efectiva adopción por parte de los usuarios del software de gestión documental, que incluya sensibilización, entrenamiento y evaluación que garantice la transferencia de conocimiento.
5. Capacitar a los usuarios técnicos y finales en el uso del software de gestión documental, la capacitación funcional y técnica se realizará en la ciudad de Bogotá.
6. Garantizar el cumplimiento de los servicios conexos y el soporte técnico por parte del contratista durante el tiempo de ejecución del contrato.
7. Suplir los requerimientos funcionales mediante los siguientes módulos: Administración, Auditoria, Correspondencia, Expediente, Archivo, Solicitudes xx Xxxxxxxx, Centro de Gestión, Consultas, Reportes, y manejo de notificaciones.
8. Implementar en el sistema la normatividad del Archivo General de la Nación (AGN) conforme a los estándares dispuestos en las Tablas de Retención Documental (TRD) en los archivos de gestión y su tránsito a las posteriores fases del ciclo vital de los documentos (Investigación institucional, Criterios de Valoración Documental Primaria y Secundaria, TRD) de una manera parametrizada y configurable y sus actualizaciones y/o modificaciones xx xxx durante la ejecución del contrato.
9. Integrar la solución con los Sistemas de la Entidad (Portal Web, Sistema de PQRD, Sistema jurisdiccional y conciliación, Sistema de Gestión de Liquidación de TASA, Correo Electrónico Certificado y Mensajería, Módulo de notificaciones y citaciones, Sistema de Procesos Administrativos) y soluciones externas relacionadas con la gestión documental y correspondencia acorde a la arquitectura de referencia.
10. Garantizar la seguridad de la información según la política de seguridad del Acuerdo 003 del 2015 del Archivo General de la Nación, protegiendo los documentos electrónicos, tanto en sus dimensiones como
sus propiedades. Los aspectos o características más importantes que debe tener son la integridad, la autenticidad, la disponibilidad y el no repudio. Y el manejo de información reservada como lo establece el literal D, del artículo 6 de la ley 1712 de 2014.
1.3 Modelo de Operación - Ciclo de vida de los documentos
Planeación de la
Gestión Documental
Producción
Gestión y
Trámite
Organización
Transferencia
Disposición de
Documentos
Preservación a
Largo Plazo
Valoración
A continuación, se describe cada una de las etapas del ciclo de vida de los documentos, de tal forma que el contratista debe considerar desarrollar un trabajo de ingeniería de requerimientos, hasta llegar a la interpretación de las necesidades por etapas, construcción de los prototipos del sistema de información y la especificación de los casos de uso o historias del usuario requeridas como insumo para el diseño, desarrollo e implementación del sistema.
Ilustración 1 Procesos de Gestión Documental Planeación de la Gestión Documental:
• Conjunto de actividades encaminadas a la planeación, generación y valoración de los documentos de la entidad, en cumplimiento con el contexto administrativo, legal, funcional y técnico. Comprende la creación y diseño de formas, formularios y documentos, análisis de procesos, análisis diplomático y su registro en el sistema de gestión documental. Contexto bajo el cual se analizarán las necesidades en gestión documental de la Entidad, bajo los requerimientos administrativos, legal, funcional y tecnológica.
Producción:
• Es la generación de documentos que producen las instituciones en cumplimiento de sus funciones. Comprende los aspectos de origen, creación y diseño de formatos y documentos, conforme al desarrollo de las funciones propias de cada entidad o dependencia y la normalización de la producción documental.
Gestión y Trámite:
• Es el curso del documento desde su producción o recepción hasta el cumplimiento de su función administrativa, comprende la trazabilidad del trámite del documento que constituye el estado inicial, la revisión, aprobación y demás componentes. En desarrollo de sus funciones, cada dependencia genera un conjunto de documentos objeto de trámites administrativos, dichos documentos integran sus respectivas series documentales. De acuerdo con la normatividad existente en el país, se deben tener en cuenta los tiempos máximos establecidos para el trámite oportuno de las comunicaciones. Adicionalmente el sistema debe permitir.
Organización:
• Se define como el conjunto de acciones orientadas a la clasificación, ordenación y descripción de los documentos de una institución, como parte integral de los procesos archivísticos de:
• Clasificación documental: Proceso archivístico mediante el cual se identifican y establecen las series que componen cada agrupación documental (fondo, sección y subsección), de acuerdo con la estructura orgánico-funcional de la entidad"
• Ordenación documental: Ubicación física de los documentos dentro de las respectivas series en el orden previamente acordado.
• Descripción documental: Es el proceso de análisis de los documentos de archivo o de sus agrupaciones, que permite su identificación, localización y recuperación, para la gestión o la investigación.
Transferencia:
• Conjunto de operaciones adoptadas por la entidad para transferir los documentos durante las fases de archivo, verificando la estructura, la validación del formato de generación, la migración, refreshing, emulación o conversión, los metadatos técnicos de formato, los metadatos de preservación y los metadatos descriptivos.
Disposición de documentos:
• Es la decisión resultante de la valoración del ciclo vital de los documentos con miras a su conservación temporal, permanente o su eliminación conforme a lo dispuesto en las Tablas de Retención Documental. La Disposición Final, implica que a cada serie o sub-serie se le aplique previamente el proceso de valoración para definir su conservación permanente, reproducción a través de tecnologías y soportes, en cuya aplicación se observen principios y procesos archivísticos, la eliminación cuando agotados sus valores administrativos no tengan o representen valor para la investigación o la selección de algunas muestras representativas.
Preservación a largo plazo:
• Es el conjunto de medidas preventivas o correctivas, adoptadas para garantizar la integridad física y funcional de los documentos de archivo, sin alterar su contenido. El almacenamiento de documentos consiste en guardar sistemáticamente documentos de archivo en espacios y unidades de conservación apropiadas. En este proceso la actividad más importante consiste en la implantación del Sistema Integrado de Conservación.
Valoración:
• Establecer las actividades técnicas y operativas para determinar los valores primarios y secundarios del patrimonio documental de la Entidad en cumplimiento del contexto administrativo, legal, técnico e histórico.
• Inicia con la planificación de los documentos para determinar sus valores primarios y secundarios, con el fin de establecer su permanencia en las diferentes fases del archivo hasta determinar su destino final (eliminación, conservación temporal o definitiva).
1.3.1 Bosquejo funcional de los módulos para el sistema de gestión documental y correspondencia.
1.4 Alcance del contrato
Teniendo en cuenta que el resultado del estudio xx xxxxxxx adelantado para el presente proceso arrojó que existe pluralidad de oferentes con productos ya construidos en el mercado, y las ventajas que esto representa para la entidad en términos de tiempo y costos, se ha definido que el producto a ofertar debe contar de forma nativa con al menos el 70% de las funcionalidades solicitadas en este documento considerando esfuerzos únicamente de parametrización, y el porcentaje restante puede ser aportado mediante desarrollos construidos en el producto, por lo cual se debe entender que las propuestas que consideren ofertar productos con desarrollo del 100% a la medida y también si la personalización es mayor al 30% de los requerimientos funcionales serán rechazadas. Dicho porcentaje será medido sobre la información que el proponente diligencie en el Anexo denominado “Porcentaje de Desarrollo a la Medida”.
La ejecución del contrato se desarrollará por fases y sub-fases, dentro de cada una de ellas se incluyen actividades y entregables necesarios para la implementación del sistema de información, las fases consideradas son:
FASE | SUB-FASE |
INICIO | Inicio |
PLANEACIÓN | Planeación |
EJECUCIÓN | Análisis |
Desarrollo | |
Pruebas | |
Despliegue | |
Estabilización | |
Monitoreo y Control | |
CIERRE | Cierre |
Dentro del marco del objeto contractual el alcance involucra:
a) Instalación y configuración del software base para el sistema de información.
b) Implementación del nuevo sistema de información para el proceso de GESTIÓN DOCUMENTAL.
c) Actividades de gestión de cambio para la implementación del sistema de información.
d) Prestar el acompañamiento en sitio para la estabilización del sistema de información, mínimo de dos
(2) meses o hasta el tiempo adicional ofertado, después del despliegue de la solución.
e) Bolsa de seiscientas (600) horas para implementar nuevas funcionalidades que se generen posteriormente a lo definido en la etapa de Ingeniería de Requerimientos y hayan surtido el proceso de Control de Cambios definido por la Supersalud.
f) Servicio de Soporte y Garantía para los sistemas de información implementados.
g) Servicio de Soporte y Garantía para el licenciamiento adquirido.
h) Transferencia de conocimiento para usuarios finales, administradores y técnicos, de acuerdo con los requerimientos funcionales definidos en este documento.
i) El contratista deberá considerar todos los mecanismos de difusión para la transferencia de conocimiento y uso del sistema de información, sin embargo, en el evento en que la entidad haya
adquirido una herramienta (e-learning) para tal fin, el contratista deberá hacer uso de esta de tal forma que queden configurados y cargados los contenidos que se requieran para las actividades de capacitación del sistema de información a proveer.
j) Capacitación formal complementaria, en Ingeniería de Requerimientos para nueve (9) funcionarios de la Supersalud.
k) El contratista deberá hacer entrega de la documentación correspondiente a los derechos de uso del licenciamiento a proveer y del código fuente de todos los componentes independientes, la personalización de la solución, el reporteador y el porcentaje de desarrollo realizado.
l) El contratista deberá realizar la totalidad de la migración de la información proveniente del sistema de información Supercor al nuevo sistema de información, según información descrita en este documento numeral 6. MIGRACIÓN.
m) El contratista deberá considerar en las estimaciones de recursos, tiempos y estrategias todos los elementos, servicios y componentes adicionales que requiere la Superintendencia Nacional de Salud, para operar de forma correcta el sistema de información para la Gestión Documental, haciendo uso de todas las funcionalidades y servicios especificados en el contenido de este documento; esto quiere decir, que estos componentes serán parte integral de la oferta económica.
n) Se debe considerar que los productos deben dar cumplimiento a la normatividad vigente y a los cambios normativos que se presenten durante la ejecución del contrato, sin generar costos adicionales para la entidad.
o) Cumplir con las políticas de calidad y parámetros seguros definidos por la Superintendencia Nacional de Salud.
2. DEFINICIÓN DE ALCANCE DEL TRABAJO Y EDT (Estructura desagregada del trabajo)
Los productos y servicios a suministrar deberán cubrir las etapas de validación de requerimientos, validación de la arquitectura, diseño detallado de los ajustes y mejoras al sistema de información, construcción, pruebas de aceptación y la puesta en operación del sistema de información.
La gestión y desarrollo de los servicios y productos derivados del alcance, así como la disponibilidad del equipo de trabajo idóneo, el aseguramiento de la calidad resultante, serán responsabilidad del Contratista.
Los procesos de ingeniería de software, gestión de servicios y gerencia de proyectos serán ejecutados de acuerdo con las mejores prácticas internacionales (CMMi, SOA, PMI, ITIL) y serán responsabilidad del Contratista.
La siguiente es la estructura propuesta para la desagregación del trabajo (EDT/WBS) del proyecto:
EDT
INICIO
PLANEACIÓN
EJECUCIÓN
CIERRE
Preparativos e inicio del
proyecto
Actas de cierre
Validación y especificación de
Planeación detallada del requerimientos proyecto de desarrollo
Validación lineamientos de arquitectura & diseño detallado del software
Alistamiento infraestructura
ambiente desarrollo / pruebas
Desarrollo/construcción mejoras
y ajustes al software del sistema de información
Configuración de tablas paramétricas
Desarrollo estrategia de cargue y consulta de la información histórica
Preparación del personal usuario del sistema de información
Elaboración documentación técnica y funcional
Pruebas integrales de aceptación de usuarios
Solución de bugs
Despliegue del sistema de información Infraestructura Producción
Migración de datos
Preparativos de la salida en vivo
Salida en Vivo
Estabilización y soporte
3. REQUERIMIENTOS FUNCIONALES
El contratista se obliga a garantizar que la solución adquirida dará cumplimiento a la implementación del sistema de información el cuál involucra la operación adecuada de todas las funcionalidades descritas en este capítulo, considerando el cumplimiento de la Directiva Presidencial 04 de 2012 y el normograma que rige el proceso de Administración de la Gestión Documental, Correspondencia y Archivo y que se encuentra publicado en el sistema de gestión de calidad de la entidad.
El Contratista debe considerar dentro de sus servicios la fase de validación detallada de los requerimientos funcionales, que a continuación se listan en alto nivel:
3.1 Acceso a la aplicación
1. Login: La aplicación debe tener una pantalla de acceso con usuario, clave y autenticar con el directorio activo de la entidad (Microsoft LDAP).
2. El servicio de Login debe estar expuesto en la plataforma de portal de la entidad (Microsoft SharePoint) para que se pueda acceder por el canal web provisto por la entidad.
3. Las pantallas de la aplicación deben poderse acceder desde cualquier navegador (Browser) xxx xxxxxxx (Ej: Explorer, Mozilla, Chrome, Opera, Safari).
4. Las consultas asociadas al centro de gestión para consultar pendientes y realizar escalamientos debe ser responsive.
3.1.1 Pantalla principal de la aplicación
1. Pantalla de Bienvenida: Una vez se autentique el usuario, la aplicación debe presentar el siguiente contenido de bienvenida:
• Descripción del Usuario que se registró.
• El proponente deberá implementar la wiki para el sistema de información objeto del presente proceso y referida en este documento, sin que genere costos de licenciamiento adicionales a la entidad para el uso de la misma y considerando su configuración, personalización y poblamiento de información.
• Contenido web en la plataforma estándar (Blogs, Wikis configurados).
• Los blogs y los wikis deben poderse configurar por el administrador de contenido del sistema.
• Los blogs serán alimentados por los autores que se configuren.
• Los wikis serán la plataforma para presentar el manual en línea de la aplicación, que describa funcionalidades y respuestas a las preguntas frecuentes (FAQ).
• Menú de la aplicación con los servicios desplegables a los que el usuario tiene configurado el acceso.
• Enlace a acceso al centro Integrado de gestión de procesos.
• Versión actual de la aplicación.
3.1.2 Módulo de Administración
3.1.2.1 Configuración y parametrización
1. El sistema debe permitir la parametrización de la interface de usuario en función de su perfil.
2. Xxxx permitir al usuario administrador consultar los roles existentes en el sistema.
3. Debe permitir al usuario administrador crear y editar un perfil mediante el uso de roles disponibles.
4. Debe permitir al usuario administrador crear los perfiles requeridos de acuerdo a la necesidad de la organización, sin necesidad de desarrollo adicional.
5. Debe permitir al usuario administrador activar usuarios que se encuentran en el directorio activo, para asignar la dependencia que pertenecen y su perfil.
6. Parametrizar los metadatos asociados a cada tipo documental según lo acordado con la Superintendencia Nacional de Salud y por cada metadato definir el tipo de dato, las validaciones que se deben realizar al ingresar la información y sus valores.
7. El sistema debe permitir la creación de agrupadores de metadatos.
8. El sistema debe permitir la creación de metadatos las cuales serán asociados en las diferentes categorías.
9. El sistema debe permitir la creación, al menos de los siguientes formatos de elementos de metadatos: alfabético; alfanumérico; numérico; de fecha; lógico (esto es, SI/NO, VERDADERO/FALSO).
10. Debe permitir adicionarles a los metadatos creados, mensajes de ayuda para el diligenciamiento por parte de los usuarios.
11. Debe permitir asignar los metadatos creados, a subseries y tipos documentales.
12. No debe existir límites en creación de metadatos.
13. Permitir la administración de la estructura de metadatos que se defina para los tipos de documentos en la Superintendencia Nacional de Salud y su asociación con las tablas de retención documental.
14. Parametrizar los campos de clasificación de la ubicación de los documentos y expedientes físicos.
15. Definir el vocabulario o tesauros del sistema de gestión documental, bancos terminológicos.
16. El sistema debe cumplir con la automatización del ciclo de vida de la gestión documental (Ver ilustración
1. Ciclo de vida de los documentos).
17. Permitir la creación, configuración y administración de trámites.
18. Crear y administrar trámites, parametrizando días de término (Hábiles o calendario) para su gestión.
19. Permitir la parametrización de las alertas informativas vía correo electrónico sobre el cumplimiento de los tiempos previamente definidos y asociados con los documentos y expedientes.
20. Llevar un control numérico de consecutivos de manera automática, para cada tipo de documento que se convertirá en el generador de identificación para los documentos.
21. El sistema debe permitir configurar los consecutivos de correspondencia y creación de expediente.
22. Permitir asociar al usuario uno o más roles dentro del sistema, asumiendo que el cargo viene heredado del Directorio activo.
23. El contador de los consecutivos de radicación de entrada y salida deberá reiniciar a partir de la fecha que indique la Supersalud.
24. Dentro de la implementación del sistema, se dejarán configurados varios tipos de radicado. Al menos: Radicado de Entrada, Radicado de salida, Comunicado internos, N° Expediente, Radicado de factura, Radicado PQRD.
25. El sistema debe permitir configurar regionales, las cuales se asocian a dependencias y estas permiten el control de la correspondencia física.
26. El sistema debe permitir configurar días no laborales, de tal manera que no se tengan en cuentan para vencimientos de radicados.
27. El sistema debe permitir configurar motivos de devolución de la correspondencia enviada físicamente, de tal manera que se pueda establecer cual implica reprogramación o cancelar el envío.
28. Debe permitir crear asuntos de radicación de documentos de entrada, de tal manera que facilite la asignación del mismo.
29. El sistema debe permitir aprobar o rechazar las solicitudes de anulación que efectúen los usuarios del sistema para los radicados de salida físicos.
30. Para aquellos que se apruebe su anulación, el sistema debe generar un Acta autoligenciando los datos como N° Radicado, Dependencia, Usuario solicitante y motivo.
31. El sistema debe retirar los radicados anulados del expediente que lo contiene para ser conservados al menos 5 años por el sistema.
32. El sistema debe permitir al administrador la carga xx xxxxxxxxxx de Office de Microsoft en formatos .doc y
.docx, los cuales cuentan con etiquetas para ser diligenciado automáticamente en el sistema, en el momento de su radicación.
33. Automatizar la generación de documentos mediante el uso xx xxxxxxxxxx normalizadas incorporadas en la definición de los procedimientos, o bien asistir al usuario en la generación de nuevas plantillas luego de realizada la implementación. Permitir la configuración xx xxxxxxxxxx y formularios para documentos y expedientes.
34. Permitir configurar la Base de Datos de Contacto de correspondencia tipificada por diferentes tipos de juzgados, entidades, con ciudad de contacto.
3.1.2.1.1 Tablas de retención documental
1. Debe permitir el sistema importar archivos CSV para valores de sección, subsección, serie, subserie y tipos documentales validando los datos y reportando los errores o inconsistencias de datos presentados. Estos valores son necesarios para la configuración de las TRD de la entidad.
2. Debe permitir el sistema configurar mediante archivos planos las TRD de cada dependencia.
3. El sistema debe proveer una funcionalidad especializada para cargar las tablas de retención desde archivos de Excel y permitir manejar varias versiones de tablas de retención.
4. El aplicativo debe permitir configurar todos los parámetros relacionados con las series documentales existentes en la entidad, esto quiere decir que puede ser importada desde archivos de Excel y puede manejar los siguientes campos mínimos:
a) Dependencia
b) Código de la dependencia
c) Serie Documental
d) Subserie Documental
e) Código de la serie
f) Código de la subserie
g) Nombre del tipo documental
h) Años de Permanencia en el Archivo Central
i) Permanencia en el Archivo de Gestión de acuerdo a TRD
j) Disposición Final (Selección, Muestreo, Microfilmación etc.)
k) Años de Permanencia en el Archivo Central
5. Permitir definir los tiempos de cierre de los expedientes.
6. Permitir definir los tiempos de permanencia de cada expediente en gestión.
7. Permitir definir los tiempos de transferencia de los expedientes al archivo central.
8. Permitir definir en la solución las políticas de la entidad con respecto a la disposición final de los documentos.
9. Soporte de políticas de retención aplicables a documentos críticos de negocio, lógicos y físicos, con base en calendarios, eventos, entre otros. Capacidad para aplicar las políticas de retención sobre carpetas, o expedientes.
10. A las subseries u expedientes, debe permitir asociar los metadatos de negocio previamente establecidos, permitiendo definir cuáles serán obligatorios de diligenciamiento y opcionales. Además, debe permitir señalar cuales serán utilizados para realizar búsquedas avanzadas de expedientes.
11. El sistema debe permitir crear tipos documentales y a estos se puedan vincular metadatos creados, tomándolos de una matriz de metadatos ordenados por categorías.
12. La vinculación de metadatos para expedientes y tipos documentales debe ser una acción altamente usable y fácil de gestionar.
13. Debe permitir vincular a un tipo documental plantillas de Word que se puedan utilizar para generar documentos en la plataforma.
14. Debe permitir al administrador del sistema generar un reporte de las secciones que se encuentran pendiente por configurar TRD.
15. El sistema no debe restringir la cantidad de niveles de jerarquías para crear las TRD.
16. El sistema debe permitir actualizar la TRD creando versiones del antes y después de modificación. Esta operación debe registrar automáticamente un histórico, estos deben conservar la estructura con la que fue creado el expediente.
17. Desde la TRD, el sistema debe permitir desactivar subseries, de tal manera que los usuarios ya no podrán crear expedientes con esas denominaciones.
18. El sistema debe conservar y aplicar la retención de los expedientes creados previamente a la desactivación.
19. El sistema debe permitir desde la TRD configurar niveles de seguridad de los expedientes a crear, al menos con niveles de seguridad abierto y confidencial.
20. Un expediente puede tener uno o varios usuarios o dependencias con permisos para alimentar el expediente, con base en la configuración dada desde las TRD.
21. El aplicativo debe permitir al administrador del sistema, configurar las tablas de retención documental y determinar las acciones a seguir sobre los expedientes durante el ciclo de vida de los documentos. A continuación, el Formato de las TRD, dónde se visualizan los campos:
3.1.2.2 Usuarios
1. Permitir la configuración de perfiles de usuarios con la posibilidad de establecer control y seguridad para la confidencialidad de documentos.
2. Permitir la creación de grupos de usuario.
3. Permitir agregar y remover usuarios activos a los grupos establecidos, deberá dejar un registro de auditoría por el evento.
4. Permitir a un usuario autorizado consultar el historial de Listado de usuarios que han pertenecido a determinado grupo.
5. Durante la ejecución del contrato la Superintendencia Nacional de Salud, definirá la asignación de permisos para acceso de los documentos de acuerdo a roles y perfiles de los procesos.
6. Permitir que el acceso a los documentos sea configurado de acuerdo con las políticas y roles definidos por el índice de información clasificada y reservada.
7. Permitir un bloqueo automático de usuarios por intentos fallidos, permitiendo la definición del máximo número de intentos de acceso.
8. Tener un módulo de administración que permita definir y modificar permisos de usuarios: permitiendo la administración central de usuarios permisos de acceso, es decir, usando un inicio de sesión único.
9. Garantizar que, si un usuario lleva a cabo una búsqueda de texto íntegro, NUNCA debe incluir en los resultados documentos de archivo a los que el usuario no tenga derecho a acceder.
10. Garantizar la confidencialidad de las consultas asociadas a las tablas de retención documental y/o tipos documentales e índice de información clasificada y reservada.
11. Parametrizar los diferentes niveles de acceso a la información por jerarquías, de acuerdo con los lineamientos del área funcional.
12. Permitir establecer roles y permisos para control a nivel de función del aplicativo, esto es, determinar de manera previa las opciones a las que pueden acceder los diferentes usuarios.
3.1.2.3 Seguridad Funcional
1. El sistema debe permitir la asignación de niveles de seguridad a los documentos electrónicos contenidos en expedientes.
2. Restringir los derechos de lectura, escritura, modificación, creación y eliminación a los documentos de acuerdo con los perfiles de los usuarios.
3. El sistema debe permitir la consulta de expedientes y documentos a los usuarios acordes con la jerarquía de las dependencias o permisos asociados.
4. El sistema debe permitir configurar diferentes niveles de seguridad desde la TRD, de manera que cuando es creado un expediente, éste hereda las propiedades asignadas por el administrador.
5. El sistema debe permitir la granularidad de la información, es decir a un expediente poder tipificarlo con tres niveles de seguridad: Abierto, jerárquico y confidencial. Al mismo tiempo permitir establecer nivel de seguridad por cada tipo documental.
6. El sistema debe soportar la aplicación automática como valor por defecto del nivel mínimo (abierto) de seguridad al expediente electrónico.
7. En la información confidencial solo puede ser consultada por los perfiles autorizados e igualmente restringir documentos de consulta por dependencias.
8. El sistema debe permitir seleccionar uno o varias dependencias que pueden modificar un mismo expediente.
9. El sistema debe permitir seleccionar uno o varios usuarios que pueden modificar un mismo expediente.
10. El sistema debe permitir seleccionar uno o varias dependencias que pueden consultar un mismo expediente.
11. El sistema debe permitir seleccionar uno o varios usuarios que pueden consultar un mismo expediente.
12. El sistema debe manejar confidencialidad de los documentos que el gestor decida de acuerdo a unas políticas definidas por el área funcional y permitir levantarlas provisionalmente.
13. El contratista debe adherirse a la política de seguridad de la información la cual se encuentra publicada en la página web de la entidad (xxxxx://xxx.xxxxxxxxxx.xxx.xx/xx- co/Paginas/Oficina%20de%20Planeaci%C3%B3n/proteccion-de-datos.aspx).
3.1.2.4 Búsqueda, recuperación y presentación
1. El sistema debe ser capaz de buscar, recuperar y presentar un expediente electrónico a partir de múltiples filtros, entre los que se incluyen: nombre del expediente, identificador del expediente entre otros.
2. El sistema debe mostrar el número total de registros de una búsqueda en la pantalla del usuario, en el centro de gestión.
3. El sistema debe permitir que los documentos, y expedientes electrónicos sean consultados en lista de resultados, para ser seleccionados y abiertos.
4. El módulo de búsqueda de expedientes y radicados debe guardar al usuario que realiza búsquedas un historial, para ser reutilizado en próximas consultas.
5. El módulo de búsqueda de expedientes y radicados del sistema debe mostrar los resultados de la búsqueda ordenados de acuerdo con el criterio de búsqueda.
6. Permitir la Indexación y búsqueda full-text (para los documentos con OCR) tanto en documentos como en metadatos en el módulo de búsqueda.
7. Permitir la definición del límite de los resultados de búsqueda por pantalla.
8. Disponer de una opción en la que se pueda consultar directamente en el radicado de salida la prueba de entrega del mismo.
9. El módulo de búsqueda de expedientes y radicados del Permitir el desplazamiento hacia adelante y hacia atrás en los resultados de búsqueda.
10. Las consultas en el sistema deben permitir visualizar los Números Únicos de Radicado de Correspondencia (NURC), con expedientes.
3.1.3 Módulo de Correspondencia
El módulo de Correspondencia (SGDE) debe ser parte integral de la plataforma, de manera que no puede ser un componente de integración o independiente de la plataforma a seleccionar.
3.1.3.1 Radicado de Entrada
1. El sistema debe cumplir en su totalidad con el Acuerdo 060 de 2001 del AGN o la norma que lo modifique adicione o derogue.
2. El sistema debe permitir radicar los documentos desde las diferentes fuentes y medios que tiene la Supersalud para recibir e integrar comunicaciones (físicas y digitales).
3. El sistema debe considerar la radicación de documentos de origen externo o interno de la Entidad.
4. El sistema debe considerar el cargue de archivos digitales como anexos a las comunicaciones.
5. El sistema debe contar con un tipo de radicado de Factura para los usuarios que lo registran desde los puntos de atención.
6. El sistema debe permitir la creación y selección de un contacto, ya sea ciudadano o empresa.
7. El sistema debe permitir con los radicados de entrada la función de asignación simple y múltiple. Ejemplo cuando un radicado debe ser tramitado por varios usuarios simultáneamente.
8. Cuando se trate de radicados de entrada digitales, el sistema debe permitir previa a su radicación, la carga del objeto digital (Ejemplo: correo electrónico).
9. El sistema debe permitir en la radicación de documentos que ingresan por correspondencia, la impresión de rótulos de identificación para incorporar al documento físico el cual incluya códigos xx xxxxxx y/o datamatrix, fecha, hora y usuario Radicador.
10. El sistema deberá adecuarse para el uso de las impresoras láser con las que cuenta actualmente la entidad.
11. El sistema debe presentar un reporte de los radicados físicos pendientes por entregar físicamente al usuario asignado.
12. Permitir la generación de un número único de radicación para los documentos de entrada al cual se le deben poder asociar números de radicados de acuerdo con los procesos institucionales.
13. Parametrizar algunos asuntos del documento de entrada, según lo definido entre las dependencias y el Grupo de Correspondencia.
14. Para la entrega de radicados físicos a los usuarios, debe llevarse a cabo un reporte a través del sistema, evitando la impresión de planillas físicas.
15. Permitir el uso de código xx xxxxxx o etiquetas RFID, en la recepción de correspondencia.
16. Permitir cambiar la dependencia destino por un funcionario asignado en el Grupo de Correspondencia, en caso de errores humanos (antes de adjuntar la imagen al radicado).
17. En el formato de radicación de entrada, si existe un documento con radicado de referencia (documento padre) debe permitir relacionarlos.
3.1.3.2 Captura de documentos digitalizados
1. El sistema debe garantizar que los documentos electrónicos de archivo que se capturen se asocien a una TRD configurada en el sistema.
2. El sistema debe validar y controlar la entrada de los metadatos mínimos obligatorios.
3. El sistema debe permitir el almacenamiento de archivos de imágenes en formatos comunes estándar como TIFF, MultiTIFF. JPEG y PDF, Video, Sonido y cualquier otro formato de contenido.
4. El sistema debe permitir, para completar el proceso de captura, que los usuarios hagan llegar a otros usuarios los documentos electrónicos.
5. El sistema debe permitir previa autorización del administrador la actualización de documentos digitalizados por baja calidad en la imagen o error humano.
3.1.4 Módulo de Centro de Gestión
1. Permitir que un documento ingrese automáticamente al flujo de trabajo desde su digitalización / creación.
2. El sistema debe contar con una bandeja que clasifica los radicados y documentos en trámite según su naturaleza.
3. Permitir que se pueda seleccionar los vencimientos de términos para trámites de uno o varios documentos que por su naturaleza no requieran ser atendidos de inmediato. Por medio de esta operación, el usuario podrá asignar una fecha al radicado.
4. Debe contar con una ayuda grafica que le permita identificar los radicados pendientes de vencimiento.
5. Proveer una bandeja de tareas pendientes donde encontrarán los trámites que tengan asignados provenientes de radicados.
6. El sistema debe permitir el cálculo de la fecha de vencimiento de los radicados, cuando este se ha establecido.
7. El centro de control debe presentar tablero de control que le muestra al usuario el número de solicitudes que están asignadas, agrupadas por tipo de solicitud, según el plazo establecido se encuentran:
A tiempo (verde),
Próximas al vencimiento (amarillo)
Vencida (rojo).
3.1.5 Gestión y trámite
1. El sistema debe permitir asignar, reasignar y trasladar un radicado de entrada a otro usuario del sistema.
2. Permitir la asignación de tareas o actividades específicas asociadas a un documento a varias personas definiendo un tiempo límite para el trámite, de forma independiente para cada responsable.
3. Permitir a los usuarios (previamente autorizados para ello) reasignar radicados de un usuario a otro nuevo de la misma dependencia.
4. El sistema debe contar con un buscador de expedientes que facilite la inclusión de radicados.
5. Para responder cualquier radicado, debe estar incluido en el expediente respectivo.
6. El sistema debe permitir responder un radicado de entrada, de manera que al radicar el de salida, se finaliza el trámite.
7. Permitir al usuario consultar o visualizar un documento que haya sido sacado de su bandeja.
8. El sistema debe facilitar los análisis de antecedentes, proyección de respuesta y tramite que haya lugar hasta la culminación del asunto.
9. El sistema debe permitir con los radicados de entrada, la delegación del mismo a varios usuarios, de tal forma que cada usuario aporte los documentos y comentarios necesarios para emitir una sola respuesta.
10. El sistema debe proveer una agenda propia que permita al usuario una ayuda grafica de los radicados pendientes por tramitar.
11. El sistema debe permitir generar radicados de salida desde la dependencia productora.
12. El sistema debe permitir la carga xx xxxxxxxxxx de Word para la generación de radicados de salida.
13. Los radicados de salida deben permitir enviar copia a otros destinatarios externos, generando diferente numero radicado.
14. Los radicados de salida deben permitir generar notificaciones a usuarios internos que pueden presentar algún tipo de interés en la generación del mismo, mediante un correo electrónico que adjunte el documento de salida.
15. Los radicados de salida, no en todos los casos deben estar asociados a otros radicados.
16. Después de radicado el documento de salida, el sistema debe convertirlo automáticamente a un formato PDF/A.
17. El sistema debe permitir generar radicados de salidas digitales y físicas. Para el primero debe enviarlo al ciudadano o empresa destinataria al correo electrónico.
3.1.5.1 Flujo de documentos internos
1. Las plantillas de Word deben contar con un buscador para su fácil recuperación.
2. A través del uso xx xxxxxxxxxx de Word, el sistema debe permitir enviar estos documentos a usuarios y estos pueden abrir y editar, los cambios realizados deben ser registrados directamente sobre el documento. En todo caso debe gestionarse una sola versión del documento.
3. La plantilla utilizada por el usuario debe alojarse nativamente en la plataforma, el cual debe permitir la edición del documento las veces que el usuario lo requiera.
4. Permitir heredar metadatos directamente sobre las plantillas de Word con datos básicos del destinatario una vez sea radicado el documento.
5. Permitir la integración de metadatos a documentos digitalizados con el fin de facilitar su búsqueda.
6. Permitir crear un documento de salida, indicando el radicado de entrada o memorando al que se asocia.
7. Permitir la captura, registro y almacenamiento de documentos (físicos, digitalizados y digitales) de forma controlada asociada a las tablas de retención documental (TRD), metadatos y con los respectivos mecanismos de seguridad.
8. Permitir definir y visualizar el(os) actor(es) involucrados en el proceso antes de que llegue al(os) usuario(s) firmante(s) de un documento.
9. Permitir definir y visualizar el(os) actor(es) asociados al documento.
10. Incluir los mecanismos necesarios para la validación de documentos firmados digitalmente.
11. Permitir visualizar desde un documento de entrada o memorando el borrador o borradores asociados con este para dar repuesta.
12. Permitir el versionamiento de los documentos que se elaboren.
13. Permitir la conversión de documentos ingresados a formato PDF/A.
14. Permitir la Inclusión de notas y subrayados en los documentos de Word utilizados para generar radicados de salida.
15. Contemplar el registro de las versiones de un flujo y su trazabilidad.
16. Los usuarios pueden monitorear el estatus de todas las instancias del flujo de trabajo en una sola visualización.
3.1.5.2 Envíos de radicados de salida físicos
1. Para las comunicaciones o documentos de salida físicos, el sistema debe asignar un estado temporal hasta tanto que sea entregado a ventanilla.
2. Los radicados de salida deben almacenarse en expedientes electrónicos del sistema.
3. Cuando se reciben en ventanilla las comunicaciones o documentos de salida físicos, el sistema debe permitir asignar un número de radicado sobre el documento en plantilla Word con generación del radicado de salida y/o el STICKER opcional, y la digitalización del radicado de salida.
4. El sistema debe permitir devolver los documentos a la dependencia productora cuando éstos no diligencien los requisitos para ser enviados por alguno de los medios de correo.
5. El sistema debe permitir la asignación de los canales (servicio motorizado o correo certificado) para el envío de correspondencia a través de terceros.
6. El sistema debe permitir la generación de planillas de envío, donde se relacione los radicados de salida a distribuir físicamente.
7. El sistema debe permitir establecer cuando ha sido entregado exitosamente un radicado de salida, en caso tal permitir su reprogramación.
8. Debe permitir seleccionar el motivo de devolución de un radicado enviado.
9. El sistema debe enviar en puntos críticos notificaciones a Outlook del usuario que tramita un documento (entregado exitosamente, devuelto, reenviado).
10. Permitir obtener información adicional y selección y registro de datos para eventualidades donde se necesite enviar a un destinatario diferente al previsto.
11. Permitir colocar el nombre de la empresa de correo por la que se envió la comunicación.
3.1.5.3 Comunicados internos electrónicos
1. El sistema debe contar con un módulo para generar comunicados internos.
2. Los comunicados internos deben permitir contar con roles de proyectores y radicadores.
3. El sistema debe permitir asociar una plantilla de Word al comunicado interno, el cual debe ser el cuerpo del comunicado interno.
4. Las plantillas de Word después de radicadas, el sistema debe convertirlas en PDF/A para efectos de conservación para que éstas hagan parte integral del expediente electrónico.
5. Los comunicados internos deben permitir seleccionar múltiples destinatarios.
6. Los comunicados internos deben ser 100% electrónicos.
7. Los destinatarios de comunicados internos pueden reasignar, incluir a expediente electrónico y responder a través mediante un comunicado interno electrónico.
8. Estas operaciones deben generar histórico en los radicados enlazados.
3.1.5.4 Radicados de salida físicos
1. Permitir que el anexo a un documento pertenezca a la misma serie y sub-serie en la que se clasificó el radicado original, de acuerdo con las TRD.
2. Permitir la anulación de un radicado cumpliendo con lo establecido en el acuerdo 060 de 2001 del AGN (El sistema debe permitir el registro de la justificación del jefe de la dependencia productora y la aprobación del Coordinador del Grupo de Correspondencia).
3. Permitir eliminar aquellos documentos que estén en estado borrador por parte del usuario productor y que se proporcione las pruebas de operaciones de que ha sido objeto los documentos.
4. Proveer un Identificador único para los radicados de salida, para evitar la duplicidad de los documentos.
5. Registrar el número de folios y anexos en la radicación de documentos.
6. Permitir cargar en los radicados de salida, la imagen del mismo con la firma. Se consideran los tres tipos de firmas (electrónica, mecánica y digital) y cada proceso definirá que tipo usar.
7. En la elaboración de radicados de salida o comunicados internos el sistema debe validar el rol del usuario productor del documento, omitiendo realizar pasos adicionales (revisar, aprobar y radicar).
8. En la generación de un radicado de salida físicos como digital, el sistema debe validar si el usuario tiene permisos para su radicación, caso contrario no debe permitirlo y debe presentar un mensaje informado esta condición.
3.1.6 Módulo Expediente SGDE
El módulo de Correspondencia, SGDE y SGDEA debe ser parte integral de la plataforma, de manera que no puede ser un componente de integración o independiente de la plataforma a seleccionar.
3.1.6.1 Creación de Expediente
1. Debe permitir al administrador o usuarios con privilegios crear expedientes en el sistema.
2. Los expedientes electrónicos deben crearse vinculando la TRD de la dependencia que lo va a gestionar. La TRD debe establecer la disposición final del expediente.
3. El expediente electrónico debe permitir elegir un usuario responsable de su gestión y un título del mismo.
4. El expediente en el momento de creación debe presentar los metadatos asociados, para ser diligenciados por el usuario.
5. El expediente debe presentar los metadatos exigidos por Archivo General de la Nación, Ministerio de la Tecnología de la Información y Gobierno en línea descrito en la Guía de Expediente electrónico.
6. El sistema debe permitir modificar los niveles de seguridad de expediente, únicamente por el usuario responsable del mismo.
3.1.6.2 Gestión de Expediente
1. Debe permitir agregar documentos electrónicos a expedientes electrónicos contenidos fuera de la plataforma o en esta, y vincularlos a un tipo documental del expediente.
2. Los expedientes del sistema deben tener vinculado tipos documentales obligatorios y opcionales para cargar.
3. El sistema debe asignar un número de identificación único para el expediente, cuyo número debe ser parametrizable por el administrador del sistema.
4. Los documentos que componen el expediente, deben heredar los tiempos de retención y conservación establecidos en la TRD.
5. Cuando es cargado un documento al expediente, el sistema debe otorgarle un número único de identificación en la plataforma.
6. Permitir la Inserción de los metadatos a cada tipo documental.
7. Debe permitir la incorporación de documentos electrónicos en diferentes formatos dispuestos la Guía de documento electrónico de Gobierno en Línea.
8. Para los documentos incorporados en el expediente, el sistema debe generar un archivo XML con los valores archivísticos como ID del expediente donde se cargó el documento, serie, subserie y demás metadatos archivísticos, Este XML debe adjuntarse en el documento PDF automáticamente por el sistema.
9. Debe permitir cargar documentos adjuntos a los tipos documentales.
10. Todas las acciones efectuadas sobre el expediente y sus documentos deben ser registradas en un historial de eventos que puede ser consultados por usuarios que tengan acceso al expediente.
11. El historial de eventos del expediente debe permitir ser exportado en formato XML, CSV o PDF.
12. El sistema debe permitir cambiar de usuario responsable del expediente electrónico, por el mismo usuario o por un rol superior, bajo un proceso supervisado.
13. Debe permitir generar índice electrónico del expediente en concordancia con lo dispuesto en la Ley 527 de 1999, y Ley 1437 de 2011 o las normas que lo reglamenten, modifiquen, adicionen o deroguen.
14. El índice electrónico debe permitir exportarse en formato XML.
15. Permitir la inclusión de forma masiva de documentos en un expediente que ya está creado en el sistema, basados en las TRD y las reglas de negocio existentes en la entidad.
16. Permitir trasladar radicados de un expediente virtual a otro.
17. Para el cierre de un expediente documental el sistema debe crear reglas de validación que permitan identificar la completitud del expediente y los requerimientos establecidos en los tipos documentales. Para el caso de exclusiones de las reglas de validación se debe permitir un campo para su respectiva justificación.
18. Identificar si el expediente está abierto o cerrado según lo establecido en la TRD.
19. Permitir la exclusión de forma masiva de documentos en un expediente que ya está creado en el sistema.
20. Permitir la creación de expedientes híbridos, electrónicos y/o digitales donde se clasifiquen los tipos documentales definidos (digitales, digitalizados, microfilm, audio, análogo, video y físicos) con los respectivos mecanismos de control de acceso y seguridad, de acuerdo a lo definido en la ley 1437 de 2011, ley 1712 de 2014 y decreto 1080 de 2015 o las normas que lo reglamenten, modifiquen, adicionen o deroguen.
21. Permitir asociar la ubicación física de un expediente físico de acuerdo con la clasificación previamente definida en el sistema, es decir para referenciar físicamente en el archivo.
22. El sistema debe automatizar los procedimientos de creación, transferencia, conservación y eliminación de expedientes electrónicos, según lo establecido en el Decreto 1080 de 2015 o las normas que lo reglamenten, modifiquen, adicionen o deroguen.
23. Generar de forma automática el índice electrónico con firma electrónica de larga duración de los documentos que constan en un expediente de forma automática en el momento de su archivo.
24. Clasificar un documento en el expediente correspondiente, desde el momento en que se ingresa al sistema, validando la serie y sub-serie documental entre el documento y el expediente.
25. Contener tanto información alfanumérica, que son atributos del flujo del documento a completar durante el trámite del mismo, como documentos creados con herramientas ofimáticas que deberán poderse añadir al expediente.
26. Permitir relacionar expedientes entre sí con el fin de facilitar el acceso a la información que corresponda durante el trámite.
27. El sistema debe permitir integrar la firma digital longeva XAdES, PAdES, CAdES a los expedientes y/o de los documentos asociados, mediante el uso de certificados válidos para la generación de firma digital reconocida, emitidos por un ente certificador abierto o cerrado.
28. Permitir referenciar radicados anteriores en los expedientes electrónicos.
29. Permitir la organización de documentos electrónicos en el expediente, mediante el uso de filtros o columnas, sin afectar la indexación, su integridad y almacenamiento.
30. Permitir Generar alertas sobre los documentos que hacen falta en el expediente electrónica, en caso que no hayan sido cargados al mismo.
3.1.6.3 Expedientes híbridos
1. Debe permitir diligenciar metadatos de ubicación para su localización física en el caso de los expedientes híbridos.
2. Los datos mínimos requeridos para referenciar físicamente los tomos son:
a) Edificio
b) Estante
c) Cara
d) Entrepaño
e) Caja
f) N° tomo
3. En caso que sea excluido un radicado físico de un expediente y sea incluido en otro, el sistema debe reportar esa novedad.
3.1.6.4 Módulo de Auditoría Funcional
1. En configuración de usuarios, debe generar un histórico donde se registre la modificación, con la siguiente estructura para todos los logs: Usuario que lo efectúa, operación, hora y fecha.
2. En la configuración de TRD, debe registrarse la creación, modificación, creando un histórico de versiones.
3. En la revisión de documentos de Word, debe almacenarse de manera automática las revisiones y aprobación por quienes han sido gestionados.
4. En radicados debe registrarse el detalle de todas las operaciones o trazabilidad por la que es gestionado, como radicado, digitalizado, distribuido, entregado, reasignado, respondido, incluido, delegado etc.
5. En expediente debe registrarse de manera automática operaciones como: inclusión de documento, exclusión, consulta, generación de índice electrónico, préstamo documental entre otros.
6. Tener un registro (log) de transacciones detallado, de manera que permita establecer las acciones efectuadas por todos los usuarios sobre el sistema.
7. Generar registros de auditoría de reemplazo de documentos, evidenciando la trazabilidad de cambio: usuario, fecha, hora, clave, proceso, dirección IP desde donde se realizó el cambio, etc.
8. Presentar la información histórica de los cambios que ha sufrido un anexo.
9. En el formato de radicación hay un campo de comentarios, siempre que se haga un comentario, si se modifica, es necesario que quede la trazabilidad de quien hizo la modificación o la observación.
3.1.7 Módulo Archivo SGDEA
3.1.7.1 Transferencias documentales - SGDEA
El módulo de Correspondencia, SGDE y SGDEA debe ser parte integral de la plataforma, de manera que no puede ser un componente de integración o independiente de la plataforma a seleccionar.
1. El sistema debe monitorear el tiempo de conservación de los expedientes electrónicos, tomando como base la fecha del último documento que contiene el expediente conforme la disposición final de la TRD de conformidad con lo definido en los acuerdos 0002 de 2014, el acuerdo 003 de 2015 y el Decreto Único del sector Cultura 1080 de 2015 demás normas concordantes.
2. El sistema debe notificar al usuario para que inicie la elaboración del inventario documental y realice la transferencia de acuerdo al calendario de transferencia.
3. El sistema debe permitir al usuario solicitar ampliación de plazo de transferencia y registrar una observación que queda documentada en el histórico del expediente.
4. El sistema debe facilitar la generación del inventario documental y su aprobación por archivo central.
5. El sistema debe permitir ingresar los diferentes tomos que hacen parte del expediente, de manera que se vean reflejados en el Formato de inventario documental - FUID.
6. El nuevo estado del expediente transferido debe ser “Archivo Central”.
7. El sistema debe presentar al archivo central, metadatos que faciliten la ubicación física para el caso de los expedientes híbridos.
8. En la transferencia del expediente electrónico, el sistema no puede degradar el contenido ni la estructura de sus documentos electrónicos; conservando todos los vínculos entre el documento y sus metadatos.
9. El sistema debe presentar un informe en el que se detalle cualquier fallo que se haya producido durante la transferencia, la exportación o el borrado. El informe deberá indicar cuáles de los registros que estaba previsto transferir han generado errores durante la operación.
10. El sistema debe permitir para casos excepcionales de expedientes transferidos al Archivo Central, la reincorporación al Archivo de Gestión, mediante una operación monitoreada y realizada por usuarios autorizados.
11. El sistema debe contar con reportes de expedientes transferidos, eliminados, en archivo de gestión y archivo central.
12. El aplicativo debe permitir configurar todos los parámetros relacionados con las series documentales existentes en la entidad, esto quiere decir que puede ser importada desde archivos de Excel al sistema y puede manejar los siguientes campos:
a. Año
b. Caja
c. | Expediente | |
d. | Identificación (C.C., Nit, N°. de Contrato, etc.) | |
e. | Estado (Activo, Inactivo, Transferido) | |
f. | Nombre del expediente | |
g. | Fecha Primer Documento | |
h. | Fecha Último Documento | |
i. | Número de folios | |
j. | Comentarios (Observaciones) | |
k. | Fecha de microfilmación | |
l. | Rollo Número | |
m. | Marginal Número | |
n. | Fecha de eliminación | |
o. | Tipo de documento a incluir (Decreto, Acta, Disponibilidad Presupuestal, etc.) | |
p. | Fecha de radicación del documento | |
q. | Número de radicación | |
r. | Ubicación o posición exacta dentro del expediente | |
s. | Número de hojas o folios | |
t. | Asunto del documento | |
u. | Fecha de cierre del expediente | |
v. | Fecha de Transferencia | |
w. | Fecha de envió al Archivo Central | |
x. | Enviado por | |
y. | Fecha de Recibido en el Archivo Central | |
z. | Recibido por | |
aa. | Número de Radicación Transferencia Conservación de expediente en Archivo Central - SGDEA |
1. Los usuarios que por permisos tuvieron acceso al expediente en gestión, pueden acceder al expediente en el SGDEA, sin embargo, cuando el usuario cambia de dependencia en caso de verse alterados los permisos sobre el expediente, estos puedan ser restablecidos.
2. Una vez se realice la transferencia del expediente electrónico al SGDEA, debe asegurar conservación, autenticidad, integridad y recuperación a medio y largo plazo conforme lo estipulado en la TRD.
3. El sistema debe evitar en todo momento que se elimine un expediente o cualquier parte de su contenido, salvo en caso de: destrucción conforme a la norma de conservación o eliminación llevada a cabo por un administrador como parte de un procedimiento auditado.
4. El sistema debe ser capaz de rastrear de forma automática los períodos de conservación asignados al expediente conforme la TRD, tomando como fecha final del documento incorporado más reciente.
5. El expediente electrónico debe permitir realizar empaquetado del mismo en un archivo .ZIP, el cual debe contener el índice electrónico y metadatos del expediente electrónico en formato XML, además copia de los documentos contenidos en el expediente.
3.1.7.3 Eliminación de expediente
1. El sistema debe monitorear el tiempo de conservación de los expedientes electrónicos e híbridos, tomando como base la fecha del último documento que contiene el expediente conforme la disposición final de la TRD para su eliminación.
2. Conviene que el sistema permita la destrucción total de expedientes concretos que según la TRD así lo indiquen, de forma que queden eliminados por completo y no se puedan restaurar con instrumentos especializados de recuperación de datos.
3. El sistema debe ser capaz de conservar los metadatos de los expedientes electrónicos eliminados y el índice electrónico para consultas posteriores.
4. El sistema debe generar el acta de eliminación de los expedientes destruidos.
3.1.7.4 Préstamos documentales en Archivo Central
1. La solicitud de préstamos documentales al archivo central debe ser un rol que se agrupa a un perfil de usuario.
2. El sistema debe permitir a los usuarios del sistema, efectuar búsquedas de expedientes o documentos transferidos al archivo central y solicitar en versión física.
3. El sistema debe permitir al Archivo Central que recibe la solicitud xx xxxxxxxx, puede aceptar o rechazar un préstamo físico, de radicado o expediente.
4. El sistema debe generar un reporte de las solicitudes enviadas y recibidas, préstamos aceptados y devoluciones entre usuarios.
5. El flujo de préstamos documentales, debe ser 100% a través de la plataforma contemplando la política cero papel.
6. El sistema debe permitir parametrizar el tiempo de vencimiento de los préstamos documentales.
7. El sistema debe ofrecer una funcionalidad que permita buscar y solicitar el préstamo de expedientes o radicado.
8. El sistema debe permitir al responsable del expediente o radicado, aceptar o rechazar el préstamo.
9. El sistema debe controlar la devolución xxx xxxxxxxx mediante el envío de notificación en caso de vencimiento.
10. El sistema debe permitir realizar la devolución xxx xxxxxxxx al usuario solicitante.
11. El sistema debe registrar en el histórico del expediente, la trazabilidad xxx xxxxxxxx documental.
3.1.8 Módulo de Reportes
1. Disponer de un Generador de reportes de la Meta Data de los documentos y su historial a través de filtros.
2. El sistema debe permitir generar información que permita el Análisis, Estadística y Consultas de la Meta Data de los documentos y su historial
3. Brindar en cada uno de los módulos funcionales servicios de Consultas paramétricas por rangos y filtros.
4. Permitir consultar y actualizar series y tipos documentales, sin perder los históricos.
5. Generar reportes de los indicadores de la gestión de los procesos documentales.
6. Los reportes que se generen deben poderse exportar a archivos planos (Ej XML, CSV) para cargue en aplicaciones que los puedan analizar como Excel.
7. Generar los siguientes reportes de Documentos radicados:
a. Por dependencia con la información del formato GDFT14.
b. Radicados por regional.
c. Radicados por medio de radicación.
d. Radicados sin digitalizar.
8. Generar reporte de salidas de documentos por dependencia y tipo de servicio.
9. Generar reporte de devoluciones de correspondencia por dependencia.
10. Generar reporte de las devoluciones por empresas de correo.
11. Generar reporte de radicados de salida para cargar planilla de empresas de correos con campos adicionales como peso del envío dependiendo del número de anexos, NURCs referenciados, etc.
12. Generar reporte de radicados de salida no enviados por dependencia y por responsables
13. Generar un reporte de documentos sin tipificar.
14. Permitir obtener un reporte mensual de los documentos enviados en un mes a través del servicio de correo y los documentos devueltos de ese mismo mes con el fin de hacer seguimiento a los mismos. Lo anterior por cuanto el reporte de devoluciones mensuales incluye todas las devoluciones que llegaron en el mes, aun cuando los documentos a los que se refiere no hayan sido enviados durante el mismo mes, sino que corresponden a envío de meses anteriores; esto para evitar la consulta de los mismos uno a uno y agilizar este proceso.
15. Los reportes definidos deben permitirse exportar a formato pdf para poderlos almacenar.
16. Para cada módulo se debe implementar dos reportes a nivel gerencial que presenten estadísticas de los datos asociados al módulo.
17. El sistema debe proveer la generación de reportes digitales para las distribuciones físicas de documentos, evitando la impresión de planillas.
3.1.9 Módulo de Manejo de Citaciones y Notificaciones
Citaciones y Notificaciones es un componente transversal que hace parte de esta contratación pero se debe desarrollar como un componente abierto o desacoplado que no quede encapsulado dentro del SGDE; en este documento se define el deber ser a alto nivel del proceso de citaciones y notificaciones, razón por la cual el contratista debe realizar un trabajo de ingeniería de requerimientos en la fase de ejecución del contrato, con el fin de brindar una solución que cumpla con las necesidades expuestas por el usuario técnico y funcional, adicional a ello se debe tener en cuenta que el componente “Citaciones y Notificaciones” debe interoperar con el Sistema de información de gestión documental (SGDE) a contratar en este proceso, con los sistemas de información de procesos disciplinarios, cobro coactivo y procesos administrativos que también se encuentran en proceso de contratación y en general con las aplicaciones con las que interactúa en el procedimiento, tales como: Empresas de mensajería, Certimail y demás sistemas de información involucrados en el proceso, para los cuales se deben construir y poner a disposición para su consumo los web services necesarios.
El contratista debe considerar que a futuro este servicio debe estar disponible para los procesos que se deban vincular y requieran consumir su servicio.
3.1.9.1 Gestión y trámite de Citaciones
Se entiende por citación el proceso por el cual la Entidad realiza una invitación a las partes involucradas en un proceso administrativo para que se presente a la Entidad con el fin de comunicarle formalmente (notificar) de un asunto relacionado con la Entidad, donde se le requiere para poder avanzar en el proceso.
Una citación suele tener los siguientes atributos:
Persona citada.
Términos de la citación (días de vigencias) asociados al proceso.
Motivo de la citación
Acto Administrativo y resolución asociados al proceso (tipos)
Fase del proceso
Persona que cita
Sitio de presentación
Advertencias con respecto al incumplimiento de la citación
Otros (depende del tipo de citación)
1. El sistema debe permitir administrar los tipos de autos o resoluciones que requieren de una citación, mediante plantillas en formato de Word, totalmente gestionables sin dependencia por el fabricante, de forma que permita la modificación por parte del administrador del sistema (SNS)
2. El sistema debe permitir parametrizar los campos de la citación dado que al ser plantillas de Word, éstas serán totalmente editables desde la plataforma a contratar, las cuales contarán con unas etiquetas máximas (10) requeridas que permitan la combinación de correspondencia.
3. El sistema debe permitir la impresión masiva de documentos (citaciones).
4. Las citaciones contarán con un formulario descrito con los atributos anteriores, el cual contendrá una plantilla de Word, que será editable desde la plataforma, siempre que sean no se halla enviado la citación.
5. El sistema debe permitir recibir y registrar las novedades de las citaciones en caso de requerir ser modificadas o anuladas siempre y cuando sean previas al momento de la cita.
6. El sistema debe permitir publicar la citación en la Página web de la Entidad.
7. El sistema debe contar con un módulo de reportes gráficos que permita obtener datos de tipos de notificaciones y citaciones, canal de envío, soporte (físico, digital), fecha de envío entre otros.
8. El módulo de Citaciones y Notificaciones debe integrarse de manera nativa o por interoperabilidad con el sistema de gestión documental a adquirir.
9. El sistema debe permitir parametrizar varios usuarios líderes en el proceso de citaciones y notificaciones.
10. El sistema debe permitir la creación de flujos de citación de una o varias dependencias de la entidad.
11. El sistema debe permitir administrar formatos de Word y gestionarse desde la plataforma a contratar para efectos de revisión y aprobación, registrando de manera automática, histórico de operaciones.
12. El sistema debe permitir configurar el usuario líder del grupo de notificaciones, el cual puede ser modificado por parte del administrador del sistema en un momento dado.
13. El sistema debe disponer de un web services para ser consumido por los diferentes sistemas de información que posee la SNS para hacer uso del módulo de citaciones y notificaciones.
3.1.9.1.1 USUARIOS GRUPO(S) DE NOTIFICACIONES – Envío comunicación y/o citación para notificación personal (física)
1. Un usuario del grupo de notificaciones recibe en la bandeja o centro de gestión de forma nativa o por medio de web services, el documento y sus anexos provenientes del área interesada.
2. El sistema debe enviar una notificación al correo del usuario responsable del(los) Grupo(s) que generan notificaciones, presentando el hipervínculo al Acto administrativo dispuesto en su bandeja.
3. El sistema debe presentar un botón "Devolver" Acto administrativo al área interesada, en caso de encontrarse inconsistencias, junto con un campo de observaciones, de forma nativa o consumiendo un web services.
4. El formulario debe contener un histórico donde se registran los eventos con mínimo los siguientes campos: Hora, fecha(s), usuario y operación.
5. El formulario debe presentar un botón "Borrar" que permite eliminar el formulario y sus anexos en caso que ya no sea requerido.
6. El responsable del(os) grupo(s) que generan notificaciones opcionalmente puede(n) con el Acto administrativo recibido, reasignar a otro usuario parametrizado de su misma dependencia de manera individual o masiva.
7. El usuario reasignado o mismo responsable incluye el formulario de Acto Administrativo al Expediente Electrónico creado este último previamente del Sistema de gestión documental.
8. El usuario reasignado o mismo responsable complementa el formulario diligenciado datos de la Citación.
9. Una vez es diligenciado la totalidad xx xxxxxx requeridos del formulario y archivado, el sistema debe permitir efectuar la operación de envió físico (Flujo que continua el grupo de correspondencia). NOTA: El sistema debe interoperar en general con las aplicaciones con las que interactúa en el procedimiento, con empresas de mensajería, cobro coactivo, procesos administrativos, procesos disciplinarios, certimail, para los cuales se deben construir y poner a disposición para su consumo los webs services necesarios.
3.1.9.1.2 USUARIOS GRUPO(S) DE NOTIFICACIONES – Envío comunicación y/o citación para notificación electrónica
1. Para él envío Electrónico, el sistema debe integrarse preferiblemente de manera nativa con el sistema de gestión documental, para generar un número radicado definitivo tan pronto es enviado al correo electrónico de la persona natural o jurídica el Acto Administrativo y sus anexos, integrando el servicio de Certimail.
2. El servicio de Certimail debe integrarse, debe informar el estado del envió electrónico, estableciendo si ha sido entregado/leído o si ha sido devuelto por el servidor de correo.
3. Para el caso que él envió electrónico no sea entregado al Buzón del correo electrónico de destino, el sistema de gestión documental debe enviar una notificación al correo del usuario responsable del Grupo de Notificaciones, indicando el motivo del mismo y presentando el hipervínculo al Acto administrativo dispuesto en su bandeja para iniciar el procedimiento como envió comunicación y/o citación para notificación personal (física).
NOTA 2: El sistema debe interoperar en general con las aplicaciones con las que interactúa en el procedimiento, entre otras con empresas de mensajería, cobro coactivo, certimail.
3.1.9.2 Gestión y trámite de Notificaciones
Una Notificación suele tener entre otros, los siguientes atributos:
Persona(s) Notificada(s): Se puede notificar las decisiones: al interesado, al representante o apoderado y a la persona debidamente autorizada por el interesado para notificarse.
Las autoridades ante quienes deben interponerse los recursos.
Los plazos en los cuales pueden interponerse los recursos.
Anotación de la fecha y la hora de entrega
Los recursos que legalmente proceden (Depende del acto administrativo para validar si se admite o no el recurso).
Otros (Dependiendo del tipo de notificación)
3.1.9.2.1 USUARIOS GRUPO(S) DE NOTIFICACIONES – Hacer citación personal
1. Una vez se presente en sitio la persona citada, se actualiza el formulario con la fecha de la notificación personal.
2. En caso de requerirse una aclaración de Acto administrativo, se carga un documento llamado "Constancia Secretarial" en los anexos del formulario.
3. En el formulario se presenta un botón llamado "Traslado de Acto Administrativo", el cual le envía un enlace al usuario que lo origino en el área interesada y la información debe actualizarse tanto en el expediente virtual como en las tablas que permitan la generación del reporte de Gestión de Notificaciones con fecha de envió (memorando/planilla), para su posterior recibo físico, archivándose el soporte de entrega.
4. El sistema debe permitir registrar las evidencias de las notificaciones que se efectúen de forma presencial.
3.1.9.2.2 USUARIOS GRUPO(S) DE NOTIFICACIONES – Notificación por Edicto
1. Cuando el interesado no comparece ni se ha hecho presente personalmente o a través de un tercero facultado como representante o apoderado, el sistema debe parametrizar los días hábiles (5 por ley), siguientes a la entrega de la Carta de Citación, habiéndose verificado que existe la respectiva prueba de entrega (guía o acuse de recibo).
2. El sistema debe alertar que se procede a realizar la Notificación por Edicto.
3. Cuando la Carta Citación haya sido devuelta por el Operador Postal Oficial o empresa de Mensajería, con alguno de los motivos expresados por la empresa de correo, se actualiza en el formulario de Citación / Comunicación, la fecha hasta cuándo va a estar publicado el Edicto en la cartelera institucional, se debe parametrizar los días hábiles en el sistema (10 por ley).
4. Pasado los 10 días hábiles, en el formulario se presenta un botón llamado "Traslado de Acto Administrativo", el cual envía un enlace al centro de gestión o bandeja al usuario que lo origino en el área interesada y la información debe actualizarse tanto en el expediente virtual como en las tablas que permitan la generación del reporte de Gestión de Notificaciones con fecha de envió (memorando/planilla) para su posterior recibo físico y archivándose el soporte de entrega.
5. El sistema debe permitir dar de baja la publicación de una notificación por Edicto, permitiendo realizar la notificación por otro medio.
6. Todas estas modificaciones deben quedar con su trazabilidad.
3.1.9.2.3 USUARIOS GRUPO(S) DE NOTIFICACIONES – Hacer Notificación por Aviso Correo Físico
1. Si el interesado no comparece ni se ha hecho presente personalmente o a través de un tercero facultado como representante o apoderado, pasados cinco (5) días hábiles siguientes a la entrega de la citación habiéndose verificado que existe la respectiva prueba de entrega (guía o acuse de recibo), se procederá a elaborar el Aviso en el Sistema de Gestión Documental el cual deberá contener: la fecha del aviso y la del acto que se notifica, la autoridad que lo expidió, los recursos que legalmente proceden, ante quien deben interponerse, los plazos respectivos y la advertencia de que la notificación se considerará surtida al finalizar el día siguiente al de la entrega del aviso en el lugar de destino.
2. A dicha comunicación se adjunta copia íntegra del Acto Administrativo (resolución/auto, anexos) que se va a notificar.
3. Se elabora documento (memorando/planilla) de devolución del acto administrativo notificado por Aviso y se traslada al área correspondiente, junto con los documentos soporte de la notificación.
4. Una vez es diligenciado la totalidad xx xxxxxx requeridos del formulario y archivado, el sistema debe permitir efectuar la operación de envió físico (Flujo que continua el grupo de correspondencia).
5. Surtida la notificación por Xxxxx, la cual se entiende surtida al día siguiente del recibo del documento en el formulario se presenta un botón llamado "Devolución de Acto Administrativo", el cual le envía un enlace al centro de gestión del usuario que lo origino en el área interesada y la información debe actualizarse tanto en el expediente virtual como en las tablas que permitan la generación del reporte de Gestión de Notificaciones con fecha de envió (memorando/planilla) para su posterior recibo físico y archivándose el soporte de entrega.
3.1.9.2.4 USUARIOS GRUPO(S) DE NOTIFICACIONES – Expedición Certificación de Firmeza
1. Pasados 8 días hábiles, siguientes a la fecha de notificación que se encuentre cargada en el sistema por interoperabilidad con el operador postal y la empresa de mensajería, el sistema debe enviar un mensaje a la bandeja de entrada de la dependencia que origino el acto administrativo señalándole que debe asignar la tarea de emisión de certificación de firmeza del acto administrativo.
2. El usuario del Grupo de Notificaciones recibirá en la bandeja de entrada un mensaje donde el área interesada asigna la tarea de certificación de firmeza de los expedientes listando el(os) hipervínculo(s) del o los expediente(s) electrónico(s) al o los cual(es) debe ingresar para consultar la información respectiva.
3. El sistema debe presentar un botón "Devolver" Acto administrativo al área interesada, en caso de encontrarse inconsistencias, junto con un campo de observaciones.
4. El sistema debe mostrar un tablero de control donde indique el estado de generación de las certificaciones de firmeza, el cual no debe superar diez (10) días hábiles.
5. El sistema debe interoperar para consultar los valores económicos de sanción a través de WebServices con el sistema que apoya el proceso del área de Procesos Administrativos.
6. El sistema haciendo la validación de los días hábiles, presenta un botón "Generar Certificación", el cual debe presentar un documento en Word con la combinación de etiquetas (aproximadamente 20).
7. El sistema debe tener la posibilidad de interoperar con otros sistemas de información internos, a fin de obtener a manera de consulta la información necesaria para generar la Certificación de Firmeza.
3.1.9.2.5 Usuarios grupo de Correspondencia
1. Cuando la citación yo comunicación es recibida físicamente por el Grupo de Correspondencia, para él envió físico a través del operador de mensajería contratado, el sistema de gestión documental debe generar un número radicado de salida definitivo (interoperabilidad).
2. Para el caso de los Actos Administrativos enviados físicamente, el sistema debe integrarse con el sistema del operador de mensajería, de forma que una vez se actualiza el estado de envió, este debe actualizar el sistema de gestión documental de la Superintendencia Nacional de Salud y cargar la guía digitalizada al expediente donde se encuentra el Acto administrativo. Se hace necesario que el operador de mensajería y del Sistema de gestión documental provean los medios para garantizar el alcance de este ítem.
3.1.9.2.6 OTROS REQUERIMIENTOS DE NOTIFICACIONES
1. Se requiere un Dashboard (tablero de control), que permita obtener información, consulta y trazabilidad de los documentos allegados por el interesado (Notificado), con gráficos en tiempo real, mediante la aplicación de filtros, que se alimente mediante el ingreso de fechas de los usuarios y cálculos propios del sistema.
2. Estos reportes deben permitir ser exportables mínimo en archivos de Excel, CSV, PDF.
3. La aplicación debe ofrecer búsquedas generales que faciliten la gestión de las citaciones y notificaciones de los actos administrativos. Estas consultas deben presentar la programación consolidada de citaciones y notificaciones para un rango de fechas con su estado de cumplimiento.
4. El sistema de debe permitir consultar para una notificación, la trazabilidad de: donde fue numerado, si requirió de citación, quién la realizo, quién lo notifica, cuándo se traslada para notificar, cómo se debe notificar, cuándo se notificó, que hay pendiente y en donde para notificar.
5. El sistema debe registrar las novedades que se presenten de una notificación (resultado, notificados, fechas, evidencias).
4. REQUERIMIENTOS NO FUNCIONALES (TÉCNICOS)
Se debe tener en cuenta que, para efectos de implementación y despliegue del sistema de información propuesto, este debe acoplarse a la plataforma de software base que actualmente tiene la entidad, la cual se describe a continuación:
Portalización: Sharepoint 2013 o superior
Framework de desarrollo: .NET 4.5
Servicio LDAP: Active Directory
Motores de bases de datos: SQL Server 2014 64 bits
Bus Empresarial de datos: Biztalk Enterprice 2012 R2
Administración de la configuración: Team Foundation System
Plataforma de virtualización: Hyper-V
Repositorio documental: CMS SharePoint
Sistemas operativos: Windows Server Datacenter 2012 R2 64 bits
En caso que el sistema propuesto requiera de componentes de software base adicionales a los que ya dispone la Supersalud, el proponente deberá cubrir el licenciamiento perpetuo del mismo, la transferencia de conocimiento técnico y administrativo y los costos de sostenibilidad del mismo deberán ser por el tiempo de garantía y soporte y por el tiempo adicional ofertado por el adjudicatario.
La Supersalud pondrá a disposición del contratista la plataforma y el licenciamiento de componentes Microsoft en los ambientes de pruebas y de producción para el funcionamiento de la solución ofertada.
El objetivo de este capítulo del documento es especificar con claridad los requerimientos técnicos (no funcionales) que debe suplir la aplicación de Gestión Documental, Correspondencia y Archivo, así como los aspectos de servicios conexos relacionados.
4.1 REQUERIMIENTOS TÉCNICOS GENERALES
Los componentes funcionales de la Aplicación se deben poder implementar de acuerdo a los siguientes lineamientos técnicos:
1. Ser parametrizable en todos sus servicios, funcionalidades, procesos e interfaces de usuario, sin que sea necesario realizar programación adicional.
2. Tener facilidades de administración para que sea realizada directamente por los usuarios finales designados por la entidad, sin necesidad de conocimientos técnicos específicos.
3. Soportar diversas formas de gestión y presentación de datos (textos, gráficos, imágenes, listas, consolidados).
4. Permitir la consulta de los datos en diferentes niveles de agregación y desagregación.
5. Tener facilidades como scripts pre-establecidos para realizar operaciones de copia de seguridad y recuperación de Backups.
6. Disponer de mecanismos para notificaciones por correo electrónico o mensajes de texto hacia móviles en los casos de alertas por reglas de negocio.
7. Permitir el almacenamiento de la información no estructurada de los documentos en “files System” y que guarde las referencias de búsqueda (Metadatos) en una Base de Datos, de acuerdo con el esquema referenciado por la Supersalud.
8. Permitir la implementación de un esquema o política de “cero papel”.
9. Cumplir con los estándares establecidos por Gobierno en línea dispuestos por el Ministerio de las Tecnología de la Información y las Comunicaciones – MINTIC. Que tengan directa relación con el alcance de la contratación y enmarcados dentro de los componentes de: TIC Para Servicios, TIC para Gobierno Abierto, Tic para la Gestión y Seguridad y Privacidad de la información.
10. Los componentes de software entregados por proveedor deben configurarse en la base de datos de configuración de la herramienta de gestión del ciclo de vida de las aplicaciones adquirida por la entidad (Microsoft ALM TFS Team Foundation Server).
11. El sistema debe cumplir con la norma técnica colombiana de accesibilidad a Páginas web, NTC 5854 y estándar: WCAG2.0 de la W3C.
12. El sistema debe estar basado en protocolo IP. De acuerdo con lo establecido en la Circular 000002 emitida por el Ministerio de Tecnologías de la Información y las Comunicaciones el 6 de julio de 2011, exige que los equipos (hardware y software), aplicaciones, plataformas y servicios “estén desarrollados e implementados sobre el Protocolo IPv6 con compatibilidad o soporte total IPv4”.
13. El sistema debe contar con alarmas o monitoreo mediante correo electrónicos que permita controlar los tiempos de los términos fijados.
14. El contratista debe apoyar la validación de los procesos y procedimientos funcionales existentes en el Sistema Integrado de Gestión y que se relacionen con la implementación del sistema y proponer las oportunidades de mejora, ajustes y aplicación de buenas prácticas a los mismos.
15. El contratista deberá considerar que, para el presente proyecto, debe proveer el ambiente de desarrollo y pruebas, de tal forma que soporten la verificación inicial (entregable No.6 del presente documento) y el soporte de la ejecución de la Ingeniería de Requerimientos. La Supersalud solo dispondrá del ambiente de pruebas y producción en la Fase de Ejecución, a partir del entregable: “Pruebas Integrales de Aceptación de Usuarios”.
4.2 PLATAFORMA
1. La arquitectura en los desarrollos de software del sistema de información debe estar orientada a servicios (SOA), y ofrecer una capa de servicios de interoperabilidad por lo cual el contratista debe presentar el diseño de la arquitectura, para aprobación del supervisor de proyecto antes de implementarlo.
2. Debe incorporar una arquitectura Web extensible a más de 2 capas.
3. Debe estar disponible sobre tecnologías WEB BASE, para el uso a través de un Browser.
4. Debe ser compatible con los navegadores web principales: Internet Explorer, Edge, Safari, Mozilla Firefox, Google Chrome, en sus versiones más recientes.
5. Debe disponer de un único Front-End que se pueda embeber o publicar en la plataforma de Intranet y Portal de la Entidad que está en Microsoft Sharepoint sobre el servidor de aplicaciones IIS (internet Information Server).
6. El sistema debe poder ser desplegado en arquitecturas de 64 bits.
7. Para implementar formularios y flujos de trabajo la aplicación debe poseer un framework que permita efectuar el modelamiento gráfico para las implementaciones (que no sea código).
8. Para poder consultar los flujos de trabajo a cargo de cada gestor, se debe permitir acceder a la plataforma por diferentes browser´s (Explorer, Chrome, Moxilla, Safari) y dispositivos (Pc´s, tablet´s o teléfonos inteligentes).
9. El sistema debe controlar el flujo de trabajo y poderlo parametrizar o definirlo de acuerdo con los procesos de negocio de la entidad.
10. El sistema debe soportar escalabilidad horizontal y vertical de la infraestructura habilitando esquemas de clustering, balanceo y replicación.
11. El sistema debe ser totalmente independiente de la topología de red utilizada. Debe operar sobre redes LAN y WAN en línea, a nivel nacional.
12. El sistema debe disponer de un mecanismo de interoperabilidad e integración que asegure la replicación de datos comunes a las demás aplicaciones de la SNS.
13. La administración de la configuración del sistema debe ser soportada y desplegada en la plataforma Microsoft Team Foundation System, propiedad de la Supersalud.
14. La aplicación debe permitir la implementación de todos sus componentes en plataformas virtuales Hyper-V.
15. Los desarrollos de la aplicación deben usar componentes de la arquitectura ofertada. Cualquier otro modelo nativo de la aplicación o desarrollo en otras plataformas que no utilice el estándar de arquitectura ofertada así ofrezca servicios de integración o interoperabilidad no dará cumplimiento a los lineamientos de normalización de la arquitectura de referencia de la solución..
16. La aplicación debe permitir la implementación sobre la base de datos en el motor Microsoft SQL Server 2008, 2012 o superior de 64 bits.
17. La aplicación debe permitir la implementación en el sistema operativo Microsoft Windows Server Enterprise 2008 y 2012 de 64 bits.
18. La aplicación debe permitir instalarse y operar en máquinas virtuales Hiper-V de la Nube Privada que dispone la entidad (Hoy en día la Infraestructura es un servicio IaaS de UNE). Es decir no debe exigir correr en máquina física para que tenga buen desempeño sino sobre máquinas virtuales.
19. La aplicación debe implementar la capa de interoperabilidad interactuando con el Bus empresarial de servicios de Microsoft BizTalk que dispone la entidad.
20. El sistema debe estar construido de manera modular, de tal forma que garantice la integridad de la información y la portabilidad a una Infraestructura como servicios (IaaS) en la Nube privada de la entidad.
21. El proveedor debe disponer de ambientes de desarrollo y pruebas de implementación considerando su propio licenciamiento de software base que sea el representativo para articular las tecnologías que la entidad dispondrá en el ambiente productivo (framework de desarrollo, motor de base de datos SQL Server, Publicar el acceso en la plataforma MS SharePoint y utilizar los servicios del ESB Biztalk).
22. La aplicación debe implementar todos los servicios de integración requeridos con otras aplicaciones de la Supersalud a través de la capa de interoperabilidad del Bus de servicios (ESB) que dispone la entidad (Microsoft BizTalk).
23. Una vez que la SUPERSALUD acepte la funcionalidad desde el ambiente de pruebas de implementación suministrado por el contratista, este deberá hacer el alistamiento de software base en la infraestructura para un ambiente de pruebas integrales y producción, donde el contratista deberá instalar, configurar y habilitar estos ambientes que son de la SUPERSALUD.
4.3 SEGURIDAD
1. El sistema debe permitir la Gestión de Seguridad de Usuarios, grupos de usuarios y asignación de Roles y perfiles de usuarios, permitiendo asociar las acciones disponibles en el sistema a roles de usuario, permitiendo parametrizar las funcionalidades que cada actor puede usar en el sistema.
2. Un usuario puede estar asociado a uno o más roles, de tal manera que los menús de navegación del sistema se muestran o despliegan dependiendo de las acciones asociadas a cada rol de usuario, permitiendo así que cuando el usuario es autenticado correctamente el sistema verifica los roles que tiene activos para otorgarle únicamente las acciones autorizadas a realizar.
3. El diseñó del sistema debe definir los criterios necesarios para asegurar la trazabilidad y auditoría sobre las acciones de creación, actualización, modificación o borrado de los componentes de información, de tal manera que la solución debe permitirle al administrador del sistema parametrizar las tablas y eventos que pueden auditarse.
4. El diseño del sistema debe tener en cuenta mecanismos que aseguren el registro histórico para poder mantener la trazabilidad de las acciones realizadas por los usuarios, contemplando el registro de auditoría que contiene información de fecha y hora, identificación del registro, tabla afectada, descripción del evento, tipo de evento, usuario que realiza la acción, identificación de sesión y dirección IP del usuario que efectuó la transacción.
5. El sistema debe proveer una consulta que permita a un usuario con los privilegios asignados, consultar los registros de auditoria, aplicando criterios de filtro (usuario, maquina, rango de fechas y tipo de operación).
6. El sistema debe integrarse con LDAP – (Lightweight Directory Access Protocol) para los procesos de inicio de sesión y autenticación. El sistema debe soportar la integración Nativa con el Active Directory de Microsoft que dispone la entidad. Para usuarios externos (por ejemplo: vigilados y ciudadanos) el mecanismo de autorización, autenticación y acceso será controlado a través del modelo de seguridad del sistema de información.
7. La aplicación debe cumplir con los lineamientos de seguridad relacionados a su utilización a través de redes públicas y privadas, garantizando la confidencialidad e integridad de la información y acceso a ella.
8. El sistema debe evidenciar que, a través de pruebas de vulnerabilidad, garantiza la seguridad de la información. Estas pruebas deben suministrar evidencia de que se usaron umbrales de seguridad para establecer niveles mínimos aceptables de calidad de la seguridad y de la privacidad.
9. El sistema debe incluir un mecanismo de cifrado de los datos que se transportan entre los diferentes componentes tecnológicos y los datos sensibles de la base de datos que representen un alto nivel de confidencialidad.
10. A nivel de la base de datos debe poder definirse reglas de validación de integridad de datos (unicidad, referencial y negocio).
11. El sistema debe garantizar el cumplimiento de la normatividad vigente en cuanto a protección de datos personales y debe permitir el manejo de excepciones previa autorización de los usuarios finales (ciudadanos).
12. El sistema debe permitir el manejo de certificados digitales en los documentos que así se definan para efectos de aprobación y digitalización. La Superintendencia Nacional de Salud, se encargará de gestionar ese servicio con un tercero avalado para tales fines, como por ejemplo Certicámara.
13. La aplicación debe implementar el mecanismo de firma o validación o autorización de documentos mediante firma mecánica o digital.
14. El sistema debe permitir la implementación de certificados digitales tanto en software como en hardware.
15. El sistema debe permitir el manejo de certificados digitales emitidos por cualquiera de las entidades certificadoras existentes en Colombia de acuerdo a la Ley 527 de 1999 y Decreto 019 de 2012.
16. El sistema debe disponer de mecanismos de firma digital de larga duración con formatos XADES, CADES o PADES, con el fin de dar cumplimiento a la ley 1437 de 2011 y Decreto 1080 de 2015.
17. Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas.
18. El sistema debe tener capacidad de resguardar y procesar la información generada o procesada dando cumplimiento a lo exigido por la Ley 1581 de 2012.
19. El sistema debe contemplar las prácticas de desarrollo seguro de aplicaciones y/o implementación segura de productos, para su naturaleza Web Enabled.
20. El sistema debe funcionar sobre protocolo SSL (certificados internos de la entidad cuando los sistemas de información sean internas y certificados validos públicamente cuando los sistemas de información estén expuestas a internet).
21. El sistema debe permitir el respaldo de la información de acuerdo a las necesidades del líder funcional de la aplicación.
22. El sistema debe incluir uso de criptografía para transacciones y/x xxxxxx sensibles según lo indiquen las normas vigentes y las necesidades específicas del negocio de acuerdo como lo determine la entidad.
23. El sistema debe asegurar los aspectos de la transacción, asegurando la información de autenticación secreta de usuario (User´s Secret Authentication Information), validando y verificando que la transacción permanezca confidencial y que se mantenga la privacidad asociada con todas las partes involucradas.
24. El sistema debe contemplar un modelo de datos que garantice base de datos única para evitar que se pueda presentar duplicidad de información.
25. En la información confidencial solo puede ser consultada por los perfiles autorizados e igualmente restringir documentos de consulta según los privilegios o permisos asociados.
26. Se usarán mecanismos de encriptación de los datos que por cuestiones de seguridad no deben viajar al servidor en texto plano, como es el caso de las contraseñas. Se guardará encriptada esta información en la base de datos utilizando para ello algoritmos de encriptación fuertes.
27. El sistema debe evidenciar que, a través de pruebas de vulnerabilidad, garantiza la seguridad de la información.
28. A nivel de la base de datos debe poder definirse reglas de validación de integridad de datos (unicidad, referencial y negocio).
29. El sistema debe manejar control de acceso y la reserva de información de acuerdo a las TRD y dependencias.
30. La plataforma debe trabajar con certificados digitales tanto en software (instalados en el navegador o en archivos P12 o PFX) como en hardware (tokens, smartcards)
31. Debe proveerse una base de datos única para evitar que se pueda presentar pérdida de información de los números de radicado de correspondencia, en el momento de realizar un backup.
32. Dada la cantidad de volumen de documentación que se genera y gestiona, la plataforma debe permitir la digitalización de documentación de forma automática, realizar OCR inteligente sobre los documentos, extracción de metadatos y firmado digital de documentos digitalizados bajo las características técnicas y legales del sistema de firmado.
33. El sistema debe permitir la integración con un proveedor de certificados digitales que permita comprobar el “time stamp” de los documentos firmados.
34. El sistema debe garantizar el cumplimiento de la normatividad vigente en cuanto a protección de datos personales y debe permitir el manejo de excepciones previa autorización de los usuarios finales (ciudadanos).
35. Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas.
36. El sistema debe tener capacidad de calificar la información generada o procesada por ellos, según Ley 1712 de 2014.
37. El sistema debe tener capacidad de resguardar y procesar la información generada o procesada dando cumplimiento a lo exigido por la Ley 1581 de 2012
38. El sistema debe ser Web Enabled, lo que facilita los procesos de despliegue y actualización del mismo, para ello debe funcionar sobre protocolo SSL (certificados internos de la entidad cuando las aplicaciones sean internas y certificados validos públicamente cuando las aplicaciones estén expuestas a internet).
39. Se usarán mecanismos de encriptación de los datos que por cuestiones de seguridad no deben viajar al servidor en texto plano, como es el caso de las contraseñas. Se guardará encriptada esta información en la base de datos utilizando para ello algoritmos de encriptación fuertes.
40. El sistema debe cerrar las transacciones luego de máximo 10 minutos de inactividad.
41. El sistema debe incluir controles de bloqueo de cuenta después de un máximo de 5 intentos erróneos a fin de evitar ataques de xxxxxx xxxxx.
00. El sistema debe permitir el respaldo de la información de acuerdo a las necesidades del líder funcional de la aplicación.
43. El sistema debe realizar adecuada asignación y acceso a la memoria.
44. El sistema debe incluir uso de criptografía para transacciones y/x xxxxxx sensibles según lo determine las normativas vigentes y las necesidades específicas del negocio de acuerdo como lo determine la entidad.
45. El sistema debe asegurar todos los aspectos de la transacción, es decir, asegurar que:
a. la información de autenticación secreta de usuario (User´s Secret Authentication Information), de todas las partes, se valide y verifique;
b. la transacción permanezca confidencial;
c. se mantenga la privacidad asociada con todas las partes involucradas;
46. El contratista debe tener implementado un sistema de gestión y aseguramiento de la calidad y la seguridad para los servicios que el proyecto demanda. Este sistema debe dar cobertura a las prácticas de Gestión de Proyectos, Gestión de Requerimientos, Diseño y Desarrollo de Software, Administración de la Configuración, Pruebas, Integración de Producto, Despliegue a usuarios, Administración de Incidentes, resolución de problemas y manejo integral del riesgo durante el ciclo de vida del desarrollo de la solución, esto se debe evidenciar mediante procedimientos formalmente documentados y
apropiados por el personal asignado al contrato, los cuales se xxxxx a conocer formalmente al supervisor técnico del contrato y se controlará su cumplimiento durante la ejecución del contrato.
47. El sistema debe cumplir con todos los lineamientos de desarrollo seguro establecidos en The OWASP Foundation recomendados en la “Guía de desarrollo OWASP” y “OWAS Cheat Sheet” y como mínimo tienen que estar protegidos y preparados para soportar ataques reportados en el top 10 de OWASP descritos a continuación:
A1– Inyección
Las fallas de inyección, tales como SQL, OS, y LDAP, ocurren cuando datos no confiables son enviados a un intérprete como parte de un comando o consulta. Los datos hostiles del atacante pueden engañar al intérprete y ejecutar comandos no intencionados o acceder datos no autorizados.
A2–Pérdida de Autenticación y Gestión de Sesiones
Las funciones de la aplicación relacionadas a autenticación y gestión de sesiones son frecuentemente implementadas incorrectamente, permitiendo a los atacantes comprometer contraseñas, claves, token de sesiones, o explotar otras fallas de implementación para asumir la identidad de otros usuarios.
A3–Secuencia de Comandos en Sitios Cruzados (XSS)
Las fallas XSS ocurren cada vez que una aplicación toma datos no confiables y los envía al navegador web sin una validación y codificación apropiada. XSS permite a los atacantes ejecutar secuencia de comandos en el navegador de la víctima los cuales pueden secuestrar las sesiones de usuario, destruir sitios web, o dirigir al usuario hacia un sitio malicioso.
A4 – Referencia Directa Insegura a Objetos
Una referencia directa a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.
A5– Configuración de Seguridad Incorrecta
Una buena seguridad requiere tener definida e implementada una configuración segura para la aplicación, xxxxxx de trabajo, servidor de aplicación, servidor web, base de datos, y plataforma. Todas estas configuraciones deben ser definidas, implementadas, y mantenidas ya que por lo general no son seguras por defecto. Esto incluye mantener todo el software actualizado, incluidas las librerías de código utilizadas por la aplicación.
A6 –Exposición de Datos Sensibles
Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Muchas aplicaciones web no protegen adecuadamente datos sensibles tales como números de tarjetas de crédito o credenciales de autenticación. Los atacantes pueden robar o modificar tales datos para llevar a cabo fraudes, robos de identidad u otros delitos. Los datos sensibles requieren de métodos de protección adicionales tales
como el cifrado de datos, así como también de precauciones especiales en un intercambio de datos con el navegador.
A7–Ausencia de Control de Acceso a las Funciones
La mayoría de aplicaciones web verifican los derechos de acceso a nivel de función antes de hacer visible en la misma interfaz de usuario. A pesar de esto, las aplicaciones necesitan verificar el control de acceso en el servidor cuando se accede a cada función. Si las solicitudes de acceso no se verifican, los atacantes podrán realizar peticiones sin la autorización apropiada.
A8–Falsificación de Peticiones en Sitios Cruzados (CSRF)
Un ataque CSRF obliga al navegador de una víctima autenticada a enviar una petición HTTP falsificada, incluyendo la sesión del usuario y cualquier otra información de autenticación incluida automáticamente, a una aplicación web vulnerable. Esto permite al atacante forzar al navegador de la víctima para generar pedidos que la aplicación vulnerable piensa son peticiones legítimas provenientes de la víctima.
A9–Uso de Componentes con Vulnerabilidades Conocidas
Algunos componentes tales como las librerías, los frameworks y otros módulos de software casi siempre funcionan con todos los privilegios. Si se ataca un componente vulnerable esto podría facilitar la intrusión en el servidor o una perdida seria de datos. Las aplicaciones que utilicen componentes con vulnerabilidades conocidas debilitan las defensas de la aplicación y permiten ampliar el rango de posibles ataques e impactos.
A10–Redirecciones y reenvíos no validados
Las aplicaciones web frecuentemente redirigen y reenvían a los usuarios hacia otras páginas o sitios web, y utilizan datos no confiables para determinar la página de destino. Sin una validación apropiada, los atacantes pueden redirigir a las víctimas hacia sitios de phishing o malware, o utilizar reenvíos para acceder páginas no autorizadas.
48. El contratista debe disponer del tiempo dentro del cronograma establecido y el sistema de información contratado para que los profesionales de la Superintendencia Nacional de Salud realicen la validación al cumplimiento de los requisitos de Seguridad antes descritos. La Superintendencia realizará pruebas de WEB PENETRATION TESTING en la fase de Ejecución tanto en la sub fase de pruebas como en la sub fase de despliegue mediante el uso de herramientas especializadas para tal fin, de igual forma la entidad efectuará una revisión del código fuente en cualquiera de las sub fases del proyecto (Análisis, Desarrollo, Pruebas, Despliegue, Estabilización, Monitoreo y Control) mediante el uso de herramientas especializadas para este fin y/o revisión de manuales elaborados, de igual manera la entidad efectuará pruebas de carga y estrés durante la sub fase de Monitoreo y control mediante el uso de scrips específicamente desarrollados para este fin. Es importante aclarar en este punto que:
El contratista deberá llevar a cabo las tareas o correcciones que puedan generarse como resultado de las validaciones efectuadas por la Superintendencia Nacional de Salud.
La Supersalud proveerá las herramientas especializadas para llevar a cabo las pruebas referenciadas en el párrafo anterior, sin embargo, es responsabilidad del contratista proveer el canal de acceso mediante el cual la Supersalud pueda conectarse con la aplicación a la cual se le realizarán las diferentes pruebas de Testing enunciadas en este capítulo.
4.4 INTEROPERABILIDAD
1. El sistema debe permitir el uso y despliegue de WebServices seguros para la integración con aplicaciones internas y externas con estándar WS-I, debe generar clientes de WebServices de forma automática a partir de la especificación WSDL del WebService, sin necesidad de programación.
2. Para todos los casos en los que se implementen servicios de interoperabilidad, se debe contar con un plan alternativo para el ingreso de información manual, el cual debe suministrar toda la trazabilidad del(os) proceso(s).
3. Los componentes de interoperabilidad (Web Services) deben ser instalados e implementados en el bus empresarial Microsoft BizTalk, propiedad de la Supersalud.
4. El sistema se debe integrar con el correo electrónico para realizar automáticamente el envío de documentos y/o notificaciones y recepción de documentos a direcciones electrónicas, utilizando protocolos estándares.
5. El sistema debe permitir la consulta e interoperar en general con los sistemas de información que la entidad tiene contemplados en la actualidad:
Aplicaciones Internas de Gestión de los procesos de la entidad:
o Proceso de Cobro Coactivo
o Citaciones y Notificaciones
o Procesos Administrativos
o Procesos Disciplinarios
o Delegada de Jurisdiccional y Conciliación
o Sistema de Gestión de liquidación de TASA
o Portal Web Institucional
o Extranet de Quejas y Reclamos.
Aplicaciones con servicios externos:
o Empresa de mensajería
o ClicSalud
o Sistema Certimail.
Los anteriores por medio de WebServices, así mismo el contratista debe considerar el ingreso de nuevos procesos a interoperar en el momento que la entidad así lo requiera.
6. El sistema debe permitir publicar WebServices en el ESB de la entidad (Ms BizTalk) para el consumo desde otras aplicaciones.
7. El sistema debe permitir la Integración con Microsoft Office.
8. Debe integrar con el correo electrónico Microsoft Office 365 para realizar automáticamente el envío de documentos y/o notificaciones y recepción de documentos a direcciones electrónicas y/o a dispositivos móviles, utilizando protocolos estándares.
9. La solución debe permitir la Integración a través de web services con el módulo de correspondencia, los repositorios de documentos para la administración de los documentos, soportes de las transacciones de cobro persuasivo y coactivo.
10. La solución debe disponer de mecanismos para adjuntar imágenes o archivos digitalizados a las transacciones de la aplicación.
11. La solución debe permitir la integración a través de web services con el sistema de procesos administrativos que permita obtener información de un proceso administrativo que puede continuar con la etapa de cobro persuasivo o coactivo.
12. La solución debe permitir la integración a través de web services con el aplicativo SGT – TASA para la utilización de los servicios de recaudo, acuerdos de pago y citaciones y notificaciones.
13. La solución debe permitir la integración a través de web services con el aplicativo BI – Inteligencia de negocios (Micro Strategy) para entregar datos fuentes para la generación de estadísticas, proyecciones o tableros gerenciales de control.
14. Permitir interoperabilidad con el software del proveedor de mensajería contratado, mediante la carga de un archivo plano, que actualice el estado de los envíos en el sistema de gestión documental, que facilite el seguimiento a las guías de envíos.
15. Permitir añadir la información de “time stamping” y estado de revocación de los documentos, con el fin de que los ficheros firmados resultantes dispongan de todos los datos necesarios para las validaciones sin necesidad de conectarse on-line a ningún servicio de la Autoridad de Certificación correspondiente.
NOTA: El contratista debe considerar que en la ejecución del contrato la entidad definirá los parámetros de la puesta en producción del sistema relacionado con los documentos existentes de acuerdo con el estado en el que se encuentren.
4.5 DOCUMENTACIÓN
El contratista debe entregar durante la ejecución del contrato la siguiente documentación en nivel desagregado que se indica en el numeral 13 “ENTREGABLES” de este documento y de acuerdo con el plan de proyecto que se presente para aprobación del supervisor técnico.
1. La documentación técnica y de usuario debe estar disponible en idioma español.
2. La documentación debe estar disponible en dos formatos:
a. Documentos: Pdf
b. Wiki: Accedida desde las pantallas de bienvenida a los sistemas de información en la capa de portalización.
3. En el evento que se ajusten funcionalidades del sistema, se debe ajustar la documentación y demás material que se vea impactado por el ajuste.
4. Al cierre del contrato se debe entregar la documentación con las versiones finales instaladas.
5. La aplicación debe disponer de la siguiente documentación:
a. Manual funcional: En donde se describan todas las funcionalidades del sistema o sistema de información, los pasos a seguir para cada función requerida, las pantallas o vistas de interfaz de usuario, los formatos de los reportes generados, índice de consultas y reportes, el manejo de las funcionalidades de administración y parametrización y administración de flujos de procesos.
b. Manual técnico: Instalación y configuración de los componentes del sistema de información, requisitos técnicos de plataforma y otros componentes (capa media y de datos), modelo de datos, arquitectura de despliegue de componentes (Diagrama de componentes físico y lógico), políticas y procedimiento de backup y recuperación de datos y capa media, administración de interfaces de integración y consideraciones de seguridad del sistema de información.
c. Manuales e instrumentos: Presentaciones y documentos para la transferencia de conocimiento técnica y funcional.
d. Documentos entregables: Los relacionados en el numeral de entregables correspondientes a las Fases de: inicio, planeación, ejecución, monitoreo y control y cierre. En medio magnético con 3 copias.
4.6 INTERFAZ DE USUARIO
1. El diseño web de los sistemas de información para los casos de consulta en dispositivos móviles debe ser adaptativo (Responsive Web Design), es decir, la apariencia de las páginas web se debe adaptar a cualquier dispositivo, incluidos los móviles (teléfonos inteligentes, tablets) manteniendo la interfaz de usuario adecuada para cada equipo en una única versión para los formularios de gestión para consultar pendientes y realizar escalamientos.
2. El sistema debe tener un único Front-End y poderse publicar o embeber en su versión final cuando termine el proyecto en la plataforma de Portal Microsoft SharePoint de la Entidad. Con ello se logrará ofrecer una única experiencia de usuario, para ello se debe realizar un trabajo de diseño y normalización de la interfaz que pueda aplicarse a cualquier aplicación que se integre a este concepto de portalización.
3. La aplicación debe afinarse junto con la infraestructura, que aporte la entidad para que los tiempos de respuesta de las consultas y las peticiones de servicios no superen los 4 segundos en consultas puntuales. Y en aquellos procesos cuyo tiempo de respuesta demande más de 5 segundos y su pertinencia sea acordada con el supervisor técnico del proyecto, la aplicación debe presentar un monitor de progreso para que el usuario lo pueda supervisar.
4. Debe proporcionar ayuda en línea en las pantallas a nivel de campo, para consultar los tipos, valores y la información por defecto que puede contener dicho campo y en idioma español.
5. La interface de la aplicación debe ser personalizable a la identidad de la Supersalud y de acuerdo con los lineamientos de la Oficina Asesora de Comunicaciones Estratégicas e Imagen Institucional de la Superintendencia.
6. El esquema de consultas y presentación de resultados debe contemplar los lineamientos establecidos a nivel de portalización bajo la plataforma de la arquitectura ofertada.
7. El sistema debe permitir la construcción de reportes y gráficos sobre la información de ejecución en tiempo real.
8. El sistema debe tener un generador propio de reportes dinámicos que podrán ser diseñados por el usuario final. Esta herramienta debe formar parte integral del sistema y no un componte de un tercero. La interfaz para diseño de reportes dinámicos debe ser intuitiva y fácil de configurar, permitiendo el acceso a la información almacenada en la base de datos del sistema de información. El resultado de estas consultas o reportes debe poderse convertir en múltiples formatos como Excel, archivos planos y Pdf.
9. El sistema debe mostrar los reportes, consultas y estadísticas por pantalla antes de su impresión.
10. El sistema debe permitir el manejo estándar de excepciones y mensajes de error, mensajes de ayuda y mensajes de confirmación.
11. El sistema debe garantizar el ingreso eficiente de la información de manera que establezca todos los controles y validaciones necesarias para garantizar la integridad y unicidad de la información.
12. El sistema debe presentar las pantallas de acceso y consulta a la información en modo gráfico e idioma español latino, no se admitirán interfaces en modo texto, ni idioma diferente al español.
13. El sistema debe disponer de estandarización de la presentación visual única en la capa de presentación a usuario final y uso en todos los módulos o componentes funcionales de la aplicación.
14. El sistema debe contar con herramientas graficas de visualización de procesos y estados.
15. Como parte de los entregables de las actividades de Diseño se deberá acordar con la supervisión técnica del proyecto los criterios de Gobierno en línea para usabilidad de la interfaz gráfica de toda la aplicación.
4.7 REQUERIMIENTOS TÉCNICOS ADICIONALES A LA GESTIÓN DOCUMENTAL
1. El sistema debe permitir Interoperabilidad con el sistema de Mensajería contratado con la empresa, con el fin de poder realizar el seguimiento a las guías que generan las empresas de correo para las entregas de las comunicaciones.
2. Permitir la Integración del correo electrónico a la gestión documental de la Superintendencia Nacional De Salud (Gestión de Correo Electrónico), tanto para los correos electrónicos que ingresen como para la correspondencia de salida a través del servicio de correo electrónico con que cuenta la Entidad.
3. Permitir el escaneo, carga y almacenamiento de documentos por puesto de trabajo, con las interfaces de hardware y software estándar compatibles con los equipos y programas utilizados en la Superintendencia Nacional de Salud.
4. Los servicios de interoperabilidad entre entidades gubernamentales seguirán el esquema de especificación gel-XML. (gel: Gobierno en Línea) e implementando mecanismos de seguridad para los Web Services.
5. La Supersalud posee actualmente un automatizador para flujos de proceso que tiene derechos patrimoniales de autor a nombre del proveedor (TRACKING AND MANAGEMENT SYSTEM-TMS) con el cual se adquirió uno de sus sistemas misionales para la entidad, teniendo en cuenta que no es posible tener total acceso a su código fuente, la Supersalud no hará uso de éste componente en otros sistemas de información, en consecuencia para el presente proceso, el oferente tendrá la posibilidad de incluir el automatizador de procesos propio del gestor documental que ofertará, para lo cual debe considerar que este componente: i) no puede generar costos de licenciamiento adicionales (licenciamiento a perpetuidad) para la presente adquisición ni para futuras anualidades y debe permitir el cumplimiento de la generación de todos los flujos y características que requiera la implementación de los procesos para el gestor documental a contratar en el presente proceso. No considero pertinente que la entidad pague por licenciamiento de la solución Gestión Documental y también deba adicionalmente pagar licenciamiento por componentes que se requieran para que ese gestor documental opere.
4.8 DE LOS COMPONENTES ARQUITECTÓNICOS
A continuación, se realiza una descripción de los aspectos adicionales que se deben cumplir con la implementación del sistema de información.
Para ello se enuncia como referencia la visión de los componentes arquitectónicos de la Entidad:
• Seguridad, auditoría y control de acceso
• Portalización
• Consultas y visualización
• Interoperabilidad
• Contenido empresarial
• Lógica de negocio
• Base de datos
• Administración de la configuración
4.8.1 Seguridad, auditoría y control de acceso
Los módulos especializados y componentes con los que se puede contar para dar cumplimiento a este componente son los siguientes:
• Módulo de seguridad: debe permitir asociar las acciones disponibles en el sistema de información a roles de usuario, permitiendo parametrizar las funcionalidades que cada actor deba usar en el sistema. Cada usuario debe poder estar asociado a uno o más roles. Los menús de navegación del sistema se muestran dependiendo de las acciones asociadas a cada rol de usuario. Cuando el usuario se autentique correctamente el sistema verificará los roles que tiene activos, para otorgarle al usuario únicamente las acciones que está autorizado a realizar.
• Módulo de auditoria: debe permitir parametrizar las tablas y eventos que puedan auditarse (creación, modificación, eliminación, consulta). Cada registro de auditoría debe contener información de fecha y hora, identificación del registro, tabla afectada, descripción del evento, tipo de evento, usuario que realiza la acción, identificación de sesión y dirección IP. Así mismo el sistema debe proveer una interfaz gráfica que permita al usuario consultar el registro de auditoria, aplicando criterios de filtro y realizando comparaciones de registro. Cada campo afectado se relacionará dentro de la información detallada del registro.
• Integración LDAP: Para los procesos de inicio de sesión y autenticación, la plataforma de gestión debe integrarse completamente con mecanismos de autenticación a través de protocolo LDAP, que se usa en la entidad con el Directorio Activo de Windows.
Se debe manejar un concepto de autenticación integrada, el cual significa que el usuario realizará el inicio de sesión por una sola vez, sobre el portal de autenticación (Microsoft Active Directory) y será re direccionado a las interfaces de la aplicación respectiva, presentando la variable de sesión para hacer efectiva el otorgamiento de permisos de acceso por aplicación y módulo. Con lo anterior se persigue que un funcionario de la Superintendencia Nacional de Salud realice un único proceso de autenticación independiente de la aplicación a la que se vaya a dirigir. Para usuarios externos (por ejemplo: vigilados y ciudadanos) el mecanismo de autorización, autenticación y acceso será controlado a través del modelo de seguridad del sistema de información.
4.8.2 Portalización
El sistema deberá considerar la personalización necesaria en el diseño gráfico de la interfaz, para atender los lineamientos del manual interno de imagen y demás aspectos relacionados a la política institucional, por lo cual presentará bocetos o plantillas de las vistas a usuario final para ser previamente aprobadas por el supervisor antes de su implementación.
El sistema debe tener un único Front-End y publicarse en el portal de Microsoft SharePoint que dispone la entidad. Con ello se logrará ofrecer una única experiencia de usuario, para ello se debe realizar un trabajo de diseño y normalización de la interfaz que pueda aplicarse a cualquier aplicación que se integre a este concepto de portalización.
Dentro de las características a definir están las condiciones establecidas por el Manual de Gobierno en Línea asociadas a: i) TIC Para Servicios, TIC para Gobierno Abierto, Tic para la Gestión y Seguridad y Privacidad de la información. ii) cumplimiento de las condiciones y características requeridas en el Manual interno de imagen corporativa de la entidad y de acuerdo con las especificaciones dadas a nivel funcional.
Se debe realizar el diseño, desarrollo y adaptación de las interfaces gráficas que se construirán sobre el único Front-end de la solución y publicarse en la plataforma del portal de la entidad que esta implementado en Microsoft SharePoint y que puedan hacer uso de servicios implementados sobre la capa de integración, a través del bus de servicios empresariales (ESB) Microsoft BizTalk. La interoperabilidad debe contemplar tanto usuarios internos como usuarios externos (ciudadanos y Entidades Externas).
La aplicación debe tener integrado el mecanismo de inicio de sesión (single sign on), a través de Directorio Activo de Windows para usuarios internos de la Superintendencia Nacional de Salud y un mecanismo alterno de registro de usuarios y autenticación para usuarios externos a través de la plataforma de gestión.
4.8.3 Consultas y visualización
El esquema de consultas y presentación de información, en el sistema a implementar debe contemplar los lineamientos establecidos a nivel de Portalización.
Para efectos de búsquedas se debe hacer uso del motor de búsquedas indexadas de la plataforma de gestión de contenido empresarial (ECM) que se oferte, la cual debe ser configurado e implementado por el contratista.
La plataforma de gestión debe proveer un componente que permita la parametrización de consultas especializadas y que habiliten acciones sobre los documentos asociados a un proceso, éste debe estar desarrollado nativamente en el gestor de contenido empresarial (ECM) que oferte el contratista de acuerdo con los requerimientos funcionales del sistema de información.
4.8.4 Interoperabilidad
El contratista dentro del proyecto de implementación realizará las actividades de configuración y parametrización de los servicios en el bus de servicios empresariales Microsoft BizTalk, provisto por la entidad, de acuerdo con todo lo requerido para la puesta en funcionamiento y correcta operación de las funcionalidades de interoperabilidad requeridas en éste anexo.
Los componentes de interoperabilidad deben exponerse sobre BizTalk y los servicios de integración relacionados con el ciclo de vida de los documentos. Estas definiciones servirán de base para la implementación futura de los servicios que orquestará el bus de servicios empresariales con otras aplicaciones que se incluyan.
4.8.5 Gestor de Contenido empresarial (ECM)
El sistema de información debe disponer de la funcionalidad y capacidad para el almacenamiento de los contenidos documentales en la plataforma ofertada. Es importante considerar que dentro del alcance se deben crear estructuras de organización archivística en función de las tablas de retención documental, para la conformación de expedientes documentales. Esto debe formar parte de la implementación del sistema de gestión documental y debe dar cumplimiento a la normatividad expedida por el Archivo general de la nación para las entidades del gobierno.
El ciclo de vida documental debe iniciar de dos maneras:
Creación de documentos desde las herramientas ofimáticas (Word, Excel, power point, etc).
Digitalización de documentos cuyo fuente son archivos físicos, caso en el cual la solución debe incorporar el esquema de OCR par que este proceso de digitalización capture de manera automática campos descriptivos de los documentos como parte de su metadata. El contratista debe garantizar que la solución brinde las herramientas, métodos y esquemas para este escenario y oriente las recomendaciones con respecto a los dispositivos de captura como impresoras o escáner de última generación que deben ser utilizados por la entidad para este fin.
Dentro de esta característica el contratista deberá considerar los servicios de:
Disponer del servicio de indexación de contenido del componente ECM ofertado
Durante el despliegue de la solución implementar dicho servicio.
Durante la transferencia de conocimiento capacitar y acompañar al personal técnico de la OTI de la SuperSalud para la realización de dicho proceso como parte de las actividades de administración del sistema una vez finalizada la ejecución del contrato.
Documentar el proceso de indexación como base de conocimiento para el personal técnico de la Supersalud.
4.8.6 Lógica de negocio
Los componentes de la capa de presentación y servicios web del sistema de información se ejecutarán sobre el servidor de aplicaciones que dispone la entidad IIS - Microsoft Internet Information Server, el cual está disponible con el sistema operativo Windows Server y serán embebidos en el portal SharePoint que dispone la entidad.
A nivel de infraestructura tecnológica se debe realizar la configuración del balanceador de carga que la arquitectura de la solución defina. Con el fin de tener alta disponibilidad y distribuir la carga de peticiones que reciban los mismos.
4.8.7 Base de datos
La plataforma de gestión, requiere que las bases de datos se ejecuten sobre Microsoft SQL Server 2012 R2. Este motor relacional forma parte de los lineamientos estándar que la Superintendencia Nacional de Salud ha definido para este componente. A nivel de base de datos se debe configurar clúster de tipo activo-activo, de acuerdo con la arquitectura de infraestructura dispuesta por la entidad.
4.8.8 Administración de la configuración
Teniendo en cuenta que la Superintendencia Nacional de Salud dispondrá de una herramienta tecnológica (Microsoft Team Foundation System) que permitirá el control de los componentes de software del sistema de información, tales como versionamiento, documentación, acceso colaborativo, entre otros; el contratista debe hacer uso de la herramienta en mención para alojar los componentes de software producto del contrato.
5. MIGRACIÓN
El contratista debe realizar el cargue de los registros y las imágenes de los documentos del sistema Supercor generados desde el año 2012 en adelante, hasta el momento en que entre en funcionamiento el nuevo sistema.
La base de datos del sistema Supercor es Documental y se encuentra en formato Lotus Domino, con extensión. nsf., razón por la cual a la fecha no existe metadata, en consecuencia, se requiere migrar la documentación (cantidad de registros) que se encuentra diligenciada en la tabla que se describe en la siguiente página. La metadata se tiene programada para la nueva versión.
El resultado del trabajo de cargue de los registros debe ser validado y aceptado por la supervisión del contrato, de acuerdo a la tabla que se describe a continuación, la evidencia de ello será la certificación emitida por la supervisión del contrato, con la aceptación de la información cargada y disponible en el sistema de información.
A continuación, se relacionan los registros (documentos) que se encuentran en la base de datos del sistema Supercor con corte a 15 xx xxxxx de 2016, sin embargo, se solicita al contratista que antes de realizar la migración, debe validar en el sistema de información Supercor la totalidad de los datos a migrar en la fecha indicada por los supervisores del contrato, debido a la variación en la transaccionalidad diaria de los documentos.
APLICACIÓN | NOMBRE DE ENTIDAD | DESCRIPCIÓN | TAMAÑO APROX. DE REGISTROS 2012 | TAMAÑO APROX. DE REGISTROS 2013 1 semestre | TAMAÑO APROX. DE REGISTROS 2013 2 semestre | TAMAÑO APROX. DE REGISTROS 2014 | TAMAÑO APROX. DE REGISTROS 2015 1 semestre | TAMAÑO APROX. E REGISTROS 2015 2 semestre | TAMAÑO APROX. DE REGISTROS 2016 |
SUPERCOR | Tabla Documental 1 Filedoc.nsf | Contiene toda la información de las | 00.000.000.000 Gb - 585.458 | 00.000.000.000 Gb - 367.549 | 00.000.000.000 Gb - 438.603 | 00.000.000.000 Gb - 717.599 | 00.000.000.000 Gb - 726.962 | 00.000.000.000 Gb - 333.698 | 00.000.000.000 Gb - 229.368 |
Entradas, Salidas y Memorandos. | documentos | documentos | documentos | documentos | documentos | documentos | documentos | ||
Tabla Documental | Permite realizar el | 184.549.376 | 184.549.376 | 184.549.376 Mb | 247.463.936 | 247.463.936 | 247.463.936 | 695.730.176 | |
2 | registro del usuario, | Mb - 45.624 | Mb - 45.624 | - 45.624 | Mb - 38.107 | Mb - 38.107 | Mb - 38.107 | Mb - 45.627 | |
Configuración.nsf | asignación de | documentos | documentos | documentos | documentos | documentos | documentos | documentos | |
código y | |||||||||
dependencias, | |||||||||
creación de | |||||||||
dependencias. | |||||||||
Tabla Documental 3 Entradas.nsf | Permite realizar el registro de las Entradas de | No hay registros | No hay registros | No hay registros | No hay registros | 384.827.392 Gb - 68.288 documentos | 384.827.392 Gb - 68.288 documentos | 384.827.392 Gb - 68.288 documentos | |
Correspondencia. | |||||||||
Tabla Documental | Permite el registro | 1.038.614.528 | 1.038.614.528 | 1.038.614.528 | 00.000.000.000 | 00.000.000.000 | 00.000.000.000 | 00.000.000.000 | |
4 Masivos2014- | de todas las | Gb - 2.672 | Gb - 2.672 | Gb - 2.672 | Gb - 109.560 | Gb - 109.560 | Gb - 109.560 | Gb - 109.560 | |
2.nsf | comunicaciones masivas que se | documentos | documentos | documentos | documentos | documentos | documentos | documentos | |
generan al exterior | |||||||||
de la Entidad. |
Tabla Documental 5 Inicio.nsf | Permite el acceso a los diferentes módulos (pantallazo de ingreso/bienvenida). | No hay registros | No hay registros | No hay registros | No hay registros | 1.245.184 Mb | 1.245.184 Mb | 1.245.184 Mb | |
Tabla Documental 6 Siadoc.nsf | Permite el registro del módulo de archivo. | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | |
Tabla Documental 7 Archivo.nsf | Permite realizar la gestión del módulo de archivo. | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | |
Tabla Documental 8 PlantillaImagen.nsf | Permite visualizar el encabezado de la aplicación. | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | |
Tabla Documental 9 Anexos.nsf | Almacena los anexos de los documentos. | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | |
Tabla Documental 10 Imágenes.nsf | Está conformada por 60 Tablas que almacena las imágenes por cada mes, desde el año 2012 en adelante. | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | |
Tabla Documental 11 Referen.nsf | Almacena los referenciados de los documentos. | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb |
APLICACIÓN | NOMBRE DE ENTIDAD | DESCRIPCIÓN | TAMAÑO APROX. DE REGISTROS 2012 | TAMAÑO APROX. DE REGISTROS 2013 1 semestre | TAMAÑO APROX. E REGISTROS 2013 2 semestre | TAMAÑO APROX. DE REGISTROS 2014 | TAMAÑO APROX. DE REGISTROS 2015 1 semestre | TAMAÑO APROX. E REGISTROS 2015 2 semestre | TAMAÑO APROX. DE REGISTROS 2016 |
SUPERCOR | Tabla Documental 1 Filedoc.nsf | Contiene toda la información de las Entradas, Salidas y Memorandos. | 00.000.000.000 Gb - 585.458 documentos | 00.000.000.000 Gb - 367.549 documentos | 00.000.000.000 Gb - 438.603 documentos | 00.000.000.000 Gb - 717.599 documentos | 00.000.000.000 Gb - 726.962 documentos | 00.000.000.000 Gb - 333.698 documentos | 00.000.000.000 Gb - 229.368 documentos |
Tabla Documental 2 Configuración.nsf | Permite realizar el registro del usuario, asignación de código y dependencias, creación de dependencias. | 184.549.376 Mb - 45.624 documentos | 184.549.376 Mb - 45.624 documentos | 184.549.376 Mb - 45.624 documentos | 247.463.936 Mb - 38.107 documentos | 247.463.936 Mb - 38.107 documentos | 247.463.936 Mb - 38.107 documentos | 695.730.176 Mb - 45.627 documentos | |
Tabla Documental 3 Entradas.nsf | Permite realizar el registro de las Entradas de Correspondencia. | No hay registros | No hay registros | No hay registros | No hay registros | 384.827.392 Gb - 68.288 documentos | 384.827.392 Gb - 68.288 documentos | 384.827.392 Gb - 68.288 documentos | |
Tabla Documental 4 Masivos2014-2.nsf | Permite el registro de todas las comunicaciones masivas que se generan al exterior de la Entidad. | 1.038.614.528 Gb - 2.672 documentos | 1.038.614.528 Gb - 2.672 documentos | 1.038.614.528 Gb - 2.672 documentos | 00.000.000.000 Gb - 109.560 documentos | 00.000.000.000 Gb - 109.560 documentos | 00.000.000.000 Gb - 109.560 documentos | 00.000.000.000 Gb - 109.560 documentos | |
Tabla Documental 5 Inicio.nsf | Permite el acceso a los diferentes módulos (pantallazo de ingreso/bienvenida). | No hay registros | No hay registros | No hay registros | No hay registros | 1.245.184 Mb | 1.245.184 Mb | 1.245.184 Mb | |
Tabla Documental 6 Siadoc.nsf | Permite el registro del módulo de archivo. | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | 17.039.360 Mb | |
Tabla Documental 7 Archivo.nsf | Permite realizar la gestión del módulo de archivo. | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | 12.320.768 Mb | |
Tabla Documental 8 PlantillaImagen.nsf | Permite visualizar el encabezado de la aplicación. | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | 1.990.656 Mb | |
Tabla Documental 9 Anexos.nsf | Almacena los anexos de los documentos. | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb - 1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | 255.066.112 Mb -1.534 documentos | |
Tabla Documental 10 Imágenes.nsf | Está conformada por 60 Tablas que almacena las imágenes por cada mes, desde el año 2012 en adelante. | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | 641,6 GB | |
Tabla Documental 11 Referen.nsf | Almacena los referenciados de los documentos. | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb | 1.242.038.272 Mb |
6. TRANSFERENCIA DE CONOCIMIENTO PARA EL USO Y ADMINISTRACIÓN DE LOS PRODUCTOS
El contratista debe elaborar y proveer el plan de transferencia de conocimiento mínimo con un mes de antelación a la implementación, el cual estará sujeto a la aprobación de la supervisión del contrato.
Capacitación Funcional:
- Se debe contemplar la transferencia de conocimiento para la totalidad de los usuarios del sistema (aproximadamente 800 usuarios), con una intensidad mínimo de cuatro 4 horas por funcionario, es decir, mínimo ciento sesenta (160) horas, para el sistema de información a implementar, que se deben distribuir en grupos por perfiles y se detallará con los supervisores del contrato, en la planeación, las sesiones de transferencia de conocimiento para los usuarios del sistema de información serán con grupos de máximo veinte (20) personas. Las capacitaciones deben dar cubrimiento a la totalidad de los usuarios del sistema para el momento de la subfase de Despliegue de la solución.
- Para la capacitación funcional se deben considerar los siguientes perfiles:
o Radicador
o Director o Jefe de dependencia
o Responsable de reparto
o Usuario gestionador
o Administrador funcional
o Auxiliar de archivo en área o dependencias de la entidad (archivo de gestión), Auxiliar de archivo en el área de gestión documental (archivo central).
o Funcionarios del área de correspondencia
- La capacitación de los perfiles mencionados en el ítem anterior,
- Realizar capacitación con una intensidad de cuarenta (40) horas mínimo para los funcionarios que tendrán el rol de administrador funcional (mínimo 10 administradores).
Capacitación Técnica:
- La transferencia de conocimiento, deberá considerar todos los temas técnicos que involucre el producto contratado (instalación, configuración de servidores de bases de datos, administración de las principales tablas de la base de datos, esquema de monitoreo al desempeño de la aplicación y sus componentes, recomendaciones para solución de problemas frecuentes, instalación de componentes, etc.).
- En general los profesionales de la Oficina de Tecnología de la entidad que se asignen al proyecto, deben adquirir el conocimiento necesario para administrar la aplicación, la base de datos y realizar configuraciones que sean requeridas por la entidad posterior a la entrega del producto y de cualquiera de sus componentes a los que la entidad pueda tener acceso.
- Realizar capacitación con una intensidad de ciento cincuenta (150) horas mínimo para los funcionarios que tendrán el rol de administrador tecnológico de la aplicación (mínimo 5 administradores).
Asuntos logísticos y herramientas de apoyo a tener en cuenta durante la Transferencia de Conocimientos
- El lugar de las sesiones de transferencia de conocimiento será en la sede principal de la Superintendencia Nacional de Salud ubicada en la ciudad de Bogotá y la entidad proveerá los equipos de cómputo requeridos que se utilizarán en las sesiones.
- Cada sesión debe contener componente teórico (máximo 30% del tiempo total de la sesión) y el restante para el componente práctico.
- El contratista debe realizar evaluaciones y hacer entrega de los resultados y listados de asistencia a la supervisión del contrato.
- El contratista debe aplicar una metodología e instrumentos de evaluación del asistente a la sesión de transferencia y del instructor. Dicha metodología indicará que el 80% de los asistentes deben obtener un puntaje superior a 80 sobre 100 para que la sesión de transferencia sea válida, de lo contrario se deberá realizar una sesión de refuerzo.
- Así mismo, se debe hacer una evaluación al instructor, quien debe obtener un puntaje promedio superior a 80 puntos sobre 100, de lo contrario el proveedor deberá cambiar el instructor y repetir la sesión dictada. Los costos adicionales por la repetición de las sesiones de transferencia, serán con cargo al contratista.
- El contratista debe considerar todos los mecanismos de difusión para la transferencia de conocimiento y uso del sistema de información, haciendo uso de la herramienta de e-learning – Moodle, dispuesta por la Supersalud, en la cual, el contratista deberá configurar y cargar todos los contenidos que se requieran para las actividades de capacitación del sistema de información a proveer.
- Para el desarrollo de las capacitaciones funcional y técnica el contratista debe entregar y proveer:
o Instructor con conocimientos técnicos y habilidades pedagógicas.
o Manuales de usuario y versión de los mismos en medio digital.
o Refrigerios para todos los asistentes a las jornadas de capacitación, en caso que las jornadas sean iguales o superiores a tres (3) horas.
o Ayudas audiovisuales del contenido de las jornadas de transferencia de conocimiento para el sistema de información, como instrumento de multiplicación para usuario final.
o Video del paso a paso funcional del sistema de información.
7. CAPACITACIÓN FORMAL
El contratista debe incluir dentro del desarrollo del contrato la entrega de certificados de asistencia para nueve
(9) funcionarios de la Supersalud, que les permita recibir curso de capacitación en el marco de referencia del ciclo de vida de requerimientos según el IREB, la cual debe cumplir con lo descrito a continuación:
INGENIERÍA DE REQUERIMIENTOS | |
Material Entregado | Material didáctico del curso, en español Certificado de asistencia individual para cada participante |
El curso | Debe ser dictado de acuerdo en los tiempos acordados en el cronograma que parte hace parte del plan de proyecto. El contratista debe aportar para esta capacitación personal certificado en el marco de referencia, con amplia experiencia laboral (Mayor a 2 años) ó acreditación de experiencia emitida por el centro de formación autorizado por el IREB. |
Duración | El entrenamiento debe contener como mínimo una duración de 24 horas. |
Lugar de desarrollo | Preferiblemente en las instalaciones de la Superintendencia Nacional de Salud o en las instalaciones que el proveedor gestione; ésta definición se dará entre el supervisor y el contratista de manera coordinada. |
Contenido del Curso | Sobre el marco de referencia del IREB, en su última versión 1. Introducción. - Síntomas y Razones de una Ingeniería de Requerimientos (IR) Inapropiada. - Las cuatro actividades principales de la IR. - El papel de la comunicación en la IR. - Características de un ingeniero de requerimientos. |
INGENIERÍA DE REQUERIMIENTOS | |
- Los tres tipos de requerimientos. - Entendiendo el rol de los requerimientos de calidad. 2. Definición de sistema y Contexto - Contexto del sistema, identificación de la diferencia entre sistema y contexto. - Especificación del límite del sistema y límite del contexto. 3. Obtención de Requerimientos - Fuentes de requerimientos. - Clasificación de requerimientos según el modelo xx Xxxx. - Técnicas de licitación de requerimientos. 4. Documentación de Requerimientos - Diseño del documento. - Formas de Representación de requerimientos. - Estructura del documento. - El uso de la documentación de requerimientos. - Criterios de calidad para el documento de requerimientos. - Criterios de calidad para la descripción de un requisito. - Glosario. 5. Documentación en Lenguaje Natural - Efectos relacionados con el lenguaje. - Construcción de requerimientos utilizando plantillas de frases. 6. Documentación Basada en Modelos - El término “modelo”. - Modelos de Objetivo. - Casos de Uso - Tres perspectivas relacionadas con los requerimientos. - Modelado desde la perspectiva estructural. - Modelado desde la perspectiva funcional. - Modelado desde la perspectiva del comportamiento. 7. Verificación y Ajuste de Requerimientos - Fundamentos de la validación de requerimientos. - Fundamentos del ajuste de requerimientos. - Evaluación de los aspectos de calidad de los requerimientos. - Validación de requerimientos en la práctica. - Técnicas para la validación de requerimientos. - Ajuste de requerimientos en la práctica. 8. Gestión de Requerimientos. - Aportar atributos a un requisito. - Diferentes vistas de requerimientos. - Priorización de requerimientos. - trazabilidad de requerimientos. - Versionado de requerimientos. - Gestión de cambios en requerimientos. 9. Herramientas de Apoyo - Herramientas. - Introducción de herramientas en una organización. - Evaluación de Herramientas. | |
Costos incluidos | Dentro del costo ofrecido y contratado para el curso Ingeniería de requerimientos, se encuentra incluido: - Certificado de Asistencia al curso. - Dos exámenes de tipo test que evalúen claridad de conceptos en los participantes. - Refrigerios cuando las jornadas de capacitación sean iguales o superiores a 3 horas. |
Fechas y horarios | Las condiciones de fecha y horario deben quedar abiertas con el fin de ser acordadas de manera coordinada entre el supervisor y el contratista. |
8. BOLSA DE HORAS
El proveedor deberá disponer de una bolsa de 600 horas destinadas para diseño, configuración, puesta en producción, despliegue y documentación, de nuevas funcionalidades o servicios, que no se encuentren dentro de los requerimientos definidos en el presente anexo, en el evento que sean requeridas por la supervisión y serán acumulables en el tiempo de la ejecución del contrato y los periodos de soporte y garantía.
El pago correspondiente al total de las horas consumidas será acumulado para el último pago de éste contrato, teniendo en cuenta sólo las horas consumidas y recibidas a satisfacción por parte de la supervisión.
El procedimiento a seguir para el consumo de estas horas se relaciona a continuación:
1. La supervisión del contrato presenta a la oficina de Tecnologías de la información la solicitud de nuevas funcionalidades requeridas en el software contratado.
2. El supervisor técnico analiza la viabilidad en conjunto con el contratista.
3. El contratista presenta estimación de requerimientos, tiempo y horas para las nuevas personalizaciones requeridas para atender la solicitud.
4. El supervisor técnico aprueba o cancela solicitud de las nuevas personalizaciones, informando al supervisor funcional el resultado del análisis realizado.
5. En caso de ser cancelada la solicitud, finaliza el procedimiento; en caso contrario continúa en el paso 6.
6. El contratista desarrolla y pone a prueba las nuevas funcionalidades.
7. La supervisión del contrato valida la nueva funcionalidad.
8. En caso de ser aprobado, la supervisión del contrato emite recibo a satisfacción, en caso contrario, lo devuelve al contratista para los ajustes correspondientes, hasta que sea nuevamente validado y aprobado.
9. GESTIÓN DE ASIMILACIÓN DEL CAMBIO
El contratista debe garantizar la implementación de un plan de gestión de asimilación del cambio que contemple estrategias y acciones que permitan establecer una dinámica de trabajo común integrado entre el contratista, las áreas funcionales que serán impactadas y la Oficina de Tecnologías de la Información (OTI), para mitigar los diferentes riesgos que surgen de manera natural en los proyectos de tecnología (retrasos en actividades, desorganización del trabajo y/o recursos, etc.). Para lograr una adopción del sistema por parte de los usuarios finales.
El plan propuesto por el contratista, estará sujeto a la aprobación del supervisor funcional del sistema de información y debe estar alineado con los lineamientos del “Plan de Gestión de Asimilación del Cambio” adoptado por la OTI en SUPERSALUD, el cual combina metodológicamente el marco HCMBOK® (Human Change Management Body of Knowledge), y el modelo ADKAR® (Awareness - Desire – Knowledge - Ability - Reinforcement) que unidos permiten direccionar el cambio en la cultura organización y el cambio personal, así como el entendimiento de motivadores, proporcionando un fundamento para las actividades que se planifican como la definición de grupos de interés, talleres, entrenamientos, comunicaciones, etc.
La gestión de asimilación del cambio para el proyecto debe responder como mínimo a los siguientes objetivos:
Lograr la participación, involucramiento y compromiso de todos los beneficiarios del cambio generado por la implementación del sistema de información.
Apoyar el cambio cultural de la organización, asociado a una adaptación al sistema de información, nuevas formas de hacer las tareas operativas, y cambios en la cultura de manejo de la información; con una visión común y comprometida.
Detectar apoyos y barreras, y establecer mecanismos para superarlas, consiguiendo que el cambio sea aceptado de forma natural.
Las actividades de gestión de asimilación del cambio deben estar presentes durante todo el ciclo de vida del proyecto, por lo que deben ser visibles en el cronograma del proyecto.
En este componente de gestión de asimilación del cambio el oferente deberá planear y ejecutar lo siguiente:
Hacer parte del comité de gestión de asimilación del cambio del proyecto.
Diseñar y presentar para aprobación las estrategias específicas para la gestión de asimilación del cambio, y ejecutar talleres dirigidos al equipo de proyecto, en estos 3 frentes: Liderazgo, Comunicación y motivación, y apropiación del sistema de información.
Planificar y diseñar el plan de asimilación de gestión del cambio, el cual en primera versión será realizado por el contratista de acuerdo con el marco: “Plan de Asimilación de Gestión del Cambio “, de la OTI. Este será socializado y acordado internamente con los supervisores y la Oficina Asesora de Comunicaciones e imagen institucional para su aprobación.
x Ejecutar el plan de comunicaciones del proyecto, según la versión aprobada del comité de Gestión de Cambio el cual será conformado al inicio del contrato.
Formular en conjunto con la Oficina Asesora de Comunicaciones de la Supersalud, la estrategia de publicidad interna y los materiales que se requieran para llevar a cabo la ejecución del componente de gestión del cambio del proyecto de implementación del Sistema de Información de Gestión Documental.
Coordinación de los planes de capacitación del proyecto y su apoyo logístico.
Organización y ejecución de eventos institucionales que favorezcan la apropiación de la solución.
Dar a conocer a los usuarios los beneficios de la solución a implementar.
Fomentar en la entidad la apropiación de buenas prácticas y el correcto uso de la solución a implementar.
Diseño y conducción de talleres para el liderazgo, alineamiento corporativo y fortalecimiento del trabajo en equipo.
Dar a conocer los beneficios de la solución a implementar a los usuarios.
Fomentar en la entidad la apropiación de buenas prácticas y el correcto uso de la solución de gestión documental a implementar.
Desarrollar una visión compartida que permita comprender a todos los actores involucrados en el proyecto, el alcance del mismo.
Generar una estrategia que permita fortalecer y motivar a los usuarios en el proyecto generando compromiso de voluntades integradas.
Diseño y producción de máximo 800 piezas de comunicación (Mugs, Termos, Portalápices y Cartillas Informativas) y campañas de sensibilización para el posicionamiento del cambio asociado a la solución a implementar.
Informar e interiorizar los nuevos procesos a los usuarios de la SNS.
Informe consolidado que contenga los resultados de los indicadores de impacto de la solución implementada y las actividades realizadas durante en el proceso de Gestión del Cambio, con los soportes de dichas actividades (actas, planillas de asistencia, temarios, lista de convocados, lista de asistentes reales, actas de entrega de los recordatorios).
Planear, definir, y ejecutar la estrategia de transferencia de conocimiento a nivel nacional para aproximadamente 800 usuarios involucrados e impactados.
10. EQUIPO MÍNIMO REQUERIDO PARA EL PROYECTO
El contrato articulará roles de la Supersalud (Grupo A) y roles del Contratista (Grupo B).
Para el Grupo A: Los Roles de la Supersalud, serán: Comité directivo (Supervisores del contrato, Patrocinadores funcionales y personal de la OTI).
Para el grupo B: Los roles del Contratista, se clasificarán en:
Grupo B-1 - Equipo Base de Proyecto: El cual debe permanecer desde el inicio del contrato hasta el fin del contrato, considerando que son los responsables de las entregas de productos.
Se considera parte de éste grupo: Gerente del Proyecto, Apoyo Gerencial, Consultor en gestión de asimilación del cambio, Arquitecto de la Soluciones y Líder técnico, Experto en Instalación y configuración de la solución ofertada y Consultor Experto en Gestión Documental.
Grupo B-2 - Equipo Extendido del Proyecto: El cual se conformará para garantizar el cubrimiento requerido para ejecutar las actividades en las diferentes fases del contrato, según la demanda.
Se considera parte de éste grupo: Analista de Requerimientos, Desarrolladores e Ingeniero de Pruebas.
Convenciones
Equipo Supersalud
Equipo Base Extendido
Ingeniero de Pruebas
Equipo de Analistas
Equipo Base
Ingeniero de Desarrollo
Líder de Analistas
Experto Instalación y Configuración soluciones Microsoft
Líder Técnico
Arquitecto de Soluciones
Experto En Gestión Documental
Apoyo Gerencial
Consultor Gestión de Cambio
Gerente del Proyecto
Personal OTI
Patrocinadores
Comité Directivo
A continuación, se describen los requerimientos que deben cumplir los profesionales del equipo base del proyecto:
ROL | FORMACIÓN | EXPERIENCIA | % DEDICACIÓN POR FASE DEL PROYECTO | |||||||
INICIO | PLANEACIÓN | ANÁLISIS | DISEÑO | DESARROLLO | PRUEBAS | IMPLEMENTACIÓN | ESTABILIZACIÓN | |||
Gerente de proyecto (1) | Profesional en Ingeniería de Sistemas o Ingeniería Electrónica o Ingeniería Industrial o Sistemas de Información. Y Certificación PMP, ó Especialización en Gestión o Gerencia de Proyectos ó Gerencia de Tecnología. | General: Experiencia profesional de mínimo 6 años. Específica: Dentro de la experiencia General aportada podrá acreditar Experiencia certificada como Gerente en al menos (3) proyectos relacionados con implementación de sistemas de información y mínimo uno de estos tres (3) proyectos debe haberse ejecutado en entidades del sector gobierno. | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% |
Apoyo Gerencial (1) | Profesional en carreras de Ingeniería o administración. Y Certificación PMP, ó Curso de Formación de mínimo 35 horas en el marco de referencia PMBOK, ó Especialización en Gestión o Gerencia de Proyectos ó Gerencia de Tecnología. | General: Experiencia profesional de mínimo 3 años. Específica: Dentro de la experiencia General aportada podrá acreditar Experiencia Apoyo a Gerencia de proyectos (actividades de planeación ó seguimiento ó monitoreo y control) en mínimo (2) proyectos relacionados con implementación de sistemas de información y mínimo uno de estos dos (2) proyectos debe haberse ejecutado en entidades del sector gobierno. | 60% | 60% | 60% | 60% | 60% | 60% | 60% | 60% |
Consultor en gestión de asimilación del cambio (1) | Profesional en Ingeniería de Sistemas o Sistemas de Información o Psicología o comunicación organizacional o Ingeniería Industrial. | General: Experiencia Profesional de 5 años. Específica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo (3) proyectos relacionados con la gestión de la asimilación del cambio en proyectos de implementación de sistemas de información. | 100% | 100% | 100% | 50% | 0% | 50% | 100% | 50% |
Arquitecto de soluciones y líder técnico (1) | Profesional en Ingeniería de Sistemas o Ingeniería electrónica o Sistemas de Información. Y Especialización en Ingeniería de Software o Arquitectura de soluciones o Certificación en SOA (Certified SOA Architect) o | General: Experiencia profesional de mínimo 4 años. Específica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo (3) proyectos | 100% | 100% | 100% | 100% | 100% | 100% | 100% | 100% |
ROL | FORMACIÓN | EXPERIENCIA | % DEDICACIÓN POR FASE DEL PROYECTO | |||||||
INICIO | PLANEACIÓN | ANÁLISIS | DISEÑO | DESARROLLO | PRUEBAS | IMPLEMENTACIÓN | ESTABILIZACIÓN | |||
Arquitectura soluciones de la plataforma ofertada. | realizando actividades de formulación e implementación de aplicaciones en el entorno tecnológico ofertado. | |||||||||
Especialista en instalación y configuración de la solución ofertada (1) | Profesional en: Ingeniero de Sistemas o Ingeniería informática o Ingeniería electrónica. Y Certificación de Arquitecto o implementador en la(s) tecnología(s) en que se desarrolló el producto ofertado. | General: Mínimo dos (2) años de experiencia profesional. Específica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo dos (2) contratos de soporte a sistemas de información bajo la misma plataforma tecnológica del producto ofertado, realizando actividades de: instalación, configuración, implementación y desarrollo. | 0% | 0% | 0% | 0% | 50% | 100% | 100% | 50% |
Consultor experto en Gestión Documental (1) | Profesional en ciencias de la información bibliotecología y archivística o profesional en ciencias de la Información y la documentación, bibliotecología y archivística o bibliotecología y archivística. | General: Experiencia Profesional de 5 años. Especifica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo (4) proyectos relacionados con proyectos de gestión documental en entidades del gobierno, con duración mínima de 4 meses cada proyecto y Participación en mínimo dos (2) proyectos de implementación de Sistema de Gestión de Documentos Electrónicos de Archivo (SGDEA). | 100% | 100% | 100% | 50% | 20% | 50% | 50% | 50% |
Analista de requerimientos (1) | Profesional en: Ingeniería de Sistemas o Ingeniería electrónica o Sistemas de Información o Ingeniería industrial. Y Formación académica (curso de entrenamiento) en los fundamentos del marco de referencia de IREB | General: Experiencia Profesional de 2 años Especifica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo (2) proyectos relacionados con desarrollo o implementación de aplicaciones desempeñándose como analista de requerimientos (levantamiento requerimientos, especificación y gestión de cambios, capacitación a usuarios), relacionados con el proyecto a | 100% | 100% | 100% | 100% | 50% | 100% | 100% | 20% |
ROL | FORMACIÓN | EXPERIENCIA | % DEDICACIÓN POR FASE DEL PROYECTO | |||||||
INICIO | PLANEACIÓN | DISEÑO | DESARROLLO | PRUEBAS | IMPLEMENTACIÓN | ESTABILIZACIÓN | ||||
contratar con duración mínima de 4 meses en cada proyecto. | ||||||||||
Desarrollador (2) | Profesionales en: Ingeniería de sistemas o sistemas de información. Y Certificación como Desarrollador en los componentes de software en la tecnología de desarrollo del producto ofertado. | General: Experiencia profesional de 2 años Específica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo 3 proyectos de desarrollo de software en los componentes de software bajo la misma plataforma tecnológica del producto ofertado con duración mínima de 3 meses cada uno. | 0% | 0% | 100% | 100% | 100% | 100% | 100% | 50% |
Ingeniero de pruebas (1) | Profesional en: Ingeniería de Sistemas o Ingeniería informática o Ingeniería Industrial Y Certificado ISTQB nivel básico. | General: Mínimo dos (2) años de experiencia profesional. Específica: Dentro de la experiencia General aportada podrá acreditar la participación en mínimo 3 contratos de desarrollo e implementación de sistemas de información, realizando actividades de Pruebas (diseño y ejecución de casos de prueba). | 0% | 0% | 25% | 100% | 100% | 100% | 100% | 100% |
NOTA 1: Es importante anotar que el contratista tiene la posibilidad de vincular personal adicional al equipo mínimo estipulado anteriormente, en caso de requerirlo teniendo en cuenta las actividades a desarrollar y la propuesta presentada sin que implique costo adicional para la Superintendencia Nacional de Salud.
NOTA 2: El porcentaje de dedicación presencial para los roles requeridos en el cuadro anterior en la sede de la Superintendencia será acorde a la dedicación porcentual para cada una de las fases del proyecto.
11. CRONOGRAMA DE ALTO NIVEL DEL PROYECTO
Para el proyecto el oferente deberá estimar la ejecución del contrato basándose en las fases y sub-fases del proyecto y en los tiempos que se relacionan en el cronograma de alto nivel que se describe a continuación, es decir los tiempos considerados para las actividades que conforman las fases y subfases estarán sujetos a la definición de la Supersalud en el cronograma de alto nivel:
VIGENCIA 2016
CRONOGRAMA PROCESO DE GESTIÓN DOCUMENTAL
VIGENCIA 2017
MES 1 MES 2 MES 3 MES 4 MES 5 MES 6 MES 7 MES 8 MES 9 MES 10 MES 11 MES 12
Inicio
Planeación
Análisis
Diseño
Desarrollo
Pruebas Unitarias Pruebas Integrales
Despliegue
Estabilización
Cierre
12. HITOS PRINCIPALES DE PAGO Y DEL CRONOGRAMA
El proyecto contempla varios hitos, o puntos de referencia que marcan eventos importantes para supervisar el progreso del proyecto. Es así como el contratista deberá considerar dentro del cronograma:
- Hitos de pago: relacionados con los pagos a facturar producto de los entregables recibidos por la Supersalud, descritos en la forma de pago.
- Hitos del proyecto: relacionados con las actividades relevantes de la ejecución del contrato según se relacionan a continuación
1. Firma de Contrato y Acta de Inicio.
2. Presentación del producto ofertado para validación del cumplimiento a la obligación de la existencia del 70% de los requerimientos funcionales existentes o ya construidos dentro del producto.
3. Presentación del Project Charter, o Acta de Constitución del Proyecto:
o Documento que autoriza formalmente un proyecto o una fase y documenta los requisitos iniciales que satisfacen las necesidades y expectativas de los interesados.
4. Kick Off o Lanzamiento oficial del Proyecto
5. Informe de Cumplimiento/validación de cómo se van a implementar los requerimientos funcionales y no funcionales del sistema de información elaborado por el Arquitecto de TI y aceptado por el Arquitecto de la OTI.
6. Informe de la validación de cumplimiento de los requerimientos de la arquitectura del sistema de información.
7. Plan de dirección del proyecto, bajo metodología PMI.
8. Entrega del Plan de proyecto.
o Plan de asimilación del cambio
o Plan detallado para Transferencia de conocimiento
o Planes subsidiarios de planeación (bajo metodología PMI)
9. Entrega del Diseño del sistema de información.
10. Entrega de la aplicación para Sub-fase de pruebas e Informe de resultado de la migración realizada.
11. Alistamiento de la Infraestructura del Ambiente de Desarrollo (Provisto por el Contratista), según requerimientos no funcionales generales.
12. Alistamiento de la Base de Configuración de los componentes tecnológicos de las funcionalidades del sistema de información en la aplicación de Microsoft TFS.
13. Informe final de resultados de las pruebas unitarias.
14. Aceptación del Poblamiento de Tablas Paramétricas.
15. Validación y Aceptación del cargue y consulta de la información histórica.
16. Evaluación resultados de la capacitación de los usuarios.
17. Aceptación de manuales de usuarios y del sistema (manual técnico).
18. Aceptación de la configuración del Ambiente de Pruebas (durante el ciclo de vida del proyecto, el ambiente será suministrado por el contratista. Una vez el proyecto haya salido en vivo la Superintendencia Nacional de Salud dispondrá la infraestructura para un ambiente de pruebas, y el contratista deberá instalar, configurar y habilitar el ambiente en mención).
19. Informe final de resultados de aceptación de los usuarios.
20. Informe de solución de BUGs detectados.
21. Despliegue del sistema de información en la Infraestructura de Producción de la Superintendencia Nacional de Salud.
22. Preparativos de la salida en vivo (Se realizará por producción escalonada o gradual).
23. Salida en Vivo 1 (Módulo o Proceso de: administración, correspondencia y expediente), de acuerdo como se defina en la fase de planeación detallada del proyecto en común acuerdo con los supervisores del contrato.
24. Salida en Vivo 2 (Módulo o Proceso de: Notificaciones y Archivo), de acuerdo como se defina en la fase de planeación detallada del proyecto en común acuerdo con los supervisores del contrato.
25. Salida en Vivo 3 (Módulos o Procesos restantes), de acuerdo como se defina en la fase de planeación detallada del proyecto en común acuerdo con los supervisores del contrato.
26. Estabilización y soporte.
27. Entrega del Código Fuente para los ajustes adicionales y alcances o módulos no existentes en la herramienta ofertada.
28. Lecciones Aprendidas.
29. Cierre y Liquidación del Proyecto.
13. ENTREGABLES
En la siguiente matriz, se desagregan las fases, sub-fases, entregables, consideraciones de aceptación mínimas y responsable del recibo a satisfacción de cada entregable.
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
1 | INICIO | INICIO | Acta de elaboración del Kick OFF del proyecto | Presentación con el contenido de aspectos relevantes para dar inicio formal del proyecto, presentado a todos los involucrados en el mismo, que incluye la revisión y aprobación de la presentación por parte de la entidad. | Supervisor Funcional Supervisor Técnico |
2 | INICIO | INICIO | Documento del Project Charter | Que incluye: Justificación del proyecto: problema, oportunidad, requisito de negocio, etc. - Objetivos medibles y criterios de éxito - Requisitos generales y límites del proyecto - Descripción general del proyecto - Riesgos preliminares - Resumen del cronograma de hitos - Desagregación de costos del contrato de acuerdo con fase, sub-fase y entregable. - Presupuesto preliminar resumido - Director del proyecto, responsabilidad y nivel de autoridad - Interesados | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
- Nombre del patrocinador y nivel de autoridad que firmará al acta de constitución del proyecto. | |||||
3 | PLANEACIÓN | PLANEACIÓN | Documento del Plan del proyecto | Descripción de objetivos del proyecto, alcance y grupos de interés, ciclo de vida del proyecto, herramientas y técnicas a utilizar, como se ejecutará y controlará el trabajo, como se realizará la gestión de la configuración y control de cambios. (Incluye en capítulos todos los planes relacionados en la matriz de entregables). Este documento debe incluir como capítulos todos los planes relacionados con la organización y gestión del proyecto. Así mismo deberá integrar desde el inicio los planes independientes de: Asimilación del cambio, Transferencia de conocimiento y plan de capacitación formal. | Supervisor Técnico Supervisor Funcional |
4 | PLANEACIÓN | PLANEACIÓN | Plan detallado para asimilación del cambio | Inventario de grupos de interés, plan detallado de manejo de los grupos de interés, metodología, instrumentos, herramientas y cronograma de actividades. | Supervisor Funcional |
5 | PLANEACIÓN | PLANEACIÓN | Plan detallado para Transferencia de conocimiento | Plan de trabajo detallado para los interesados, metodología, instrumentos, herramientas y cronograma de actividades. | Supervisor Funcional Supervisor Técnico |
6 | PLANEACIÓN | PLANEACIÓN | Documento de validación del producto contratado en relación con el cumplimiento de los requerimientos funcionales y no funcionales | El producto contratado deberá presentarse a la Supersalud 15 días después de la firma de Acta de Inicio para verificación del cumplimiento de requerimientos funcionales y no funcionales descritos en el Anexo Técnico. | Supervisor Funcional Supervisor Técnico |
7 | EJECUCIÓN | ANÁLISIS | Informe de aprobación de Especificación detallada de requerimientos | Documento de especificación detallada de requerimientos. | Supervisor Funcional Supervisor Técnico |
8 | EJECUCIÓN | ANÁLISIS | Documento de Análisis de Requerimientos Funcionales, no Funcionales y de migración | Documento de especificación detallada de requerimientos funcionales, no funcionales y de migración (Análisis de la Arquitectura de Referencia de la solución) | Supervisor Funcional Supervisor Técnico |
9 | EJECUCIÓN | ANÁLISIS | Certificación del ambiente de Pruebas y Desarrollo del Contratista | Comprobación de la lista de chequeo validado por el supervisor. | Supervisor Técnico |
10 | EJECUCIÓN | DISEÑO | Documento que contenga el Árbol funcional de implementación de requerimientos | Árbol funcional de implementación de requerimientos para cada módulo. | Supervisor Funcional |
11 | EJECUCIÓN | DISEÑO | Informe de resultados aprobación prototipos acordados | Informe de resultados aprobación prototipos acordados para cada módulo. | Supervisor Funcional |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
12 | EJECUCIÓN | DISEÑO | Documento - Guías de configuración de la aplicación | Documento que contenga todos los pasos de parametrización de las variables clave y tablas maestras para el funcionamiento de los módulos. | Supervisor Funcional Supervisor Técnico |
13 | EJECUCIÓN | DISEÑO | Diseño de los desarrollos a la medida para los componentes de Citaciones y Notificaciones, servicios web, reportes, mecanismos de firmas y los demás que se requieran para la solución | Diagrama de clases, modelo de datos y capa de presentación de los desarrollos. | Supervisor Funcional Supervisor Técnico |
14 | EJECUCIÓN | DISEÑO | Diseño funcional de las aplicaciones y Diseño de los lineamientos gráficos y experiencia del usuario | Producto prototipado que refleje las funcionalidades solicitadas en ambiente de pruebas. (Software compilado y desplegado en ambiente de pruebas con la definición y uso práctico de la Interfaz de usuario (formularios), funcionalidades (siempre y cuando éstas no requieran reglas complejas, o información que dependa de modelo de datos que en la presente fase aún no se disponga), validaciones generales. El Diseño y funcionalidades debe considerar: i) cumplimiento a los lineamientos del Manual de Gobierno en Línea asociados a TIC Para Servicios, TIC para Gobierno Abierto, Tic para la Gestión y Seguridad y Privacidad de la información. ii) cumplimiento de las condiciones y características requeridas en el Manual interno de imagen corporativa de la entidad. iii) integración del diseño con el portal institucional desde donde se accederá a la aplicación. iv) Plan de pruebas Evidenciadas en el informe de aprobación Diseño de los lineamientos gráficos y experiencia del usuario. | Supervisor Funcional Supervisor Técnico |
15 | EJECUCIÓN | DISEÑO | Diseño del sistema de información | Arquitectura de alto nivel de la solución, arquitectura de software lógica, física y de despliegue con los componentes y relaciones entre sí, arquitectura detallada de datos (componentes y relaciones, descripción detallada de la arquitectura de la infraestructura (componentes y relaciones), lineamientos de diseño gráfico. Se debe acompañar el entregable con un cuadro que desagregue el valor de cada uno de los módulos de la aplicación; dichos valores serán la base para cuantificar penalizaciones que se presenten por incumplimiento de ANS y la certificación de la validación de lo descrito anteriormente. | Supervisor Técnico |
16 | EJECUCIÓN | DISEÑO | Documento que contenga la estrategia de: i) migración de datos históricos y poblamientos de tablas y ii) Plan de Pruebas parciales e integrales de acuerdo con el cronograma establecido para las fases | Documento que contiene la estrategia del desarrollo de cargue y consulta de datos históricos y poblamiento de tablas a migrar. El plan de pruebas deberá contener el paso a paso de las pruebas parciales e integrales de tal forma que se pueda evidenciar el cumplimiento de todos los requerimientos funcionales y no funcionales de la solución. | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
17 | EJECUCIÓN | DISEÑO | Plan de capacitación formal y listas de asistencia que evidencien la realización de cursos de capacitación formal. | El contratista deberá presentar un plan para realizar las capacitaciones incluyendo el cronograma de fechas propuestas, también deberá entregar los certificados y lista de asistencia de los funcionarios de la Supersalud a los cursos contratados. Se debe entregar el original y copia en PDF de los certificados expedidos a las personas que recibieron los cursos de capacitación. | Supervisor Técnico |
18 | EJECUCIÓN | DESARROLLO / CONFIGURACI ÓN | Informe de avance mensual de desarrollos | Que incluye: Estado de la matriz de trazabilidad de implementación de requerimientos de acuerdo con las fases del ciclo de vida del producto, Inventario de activos de software de la solución. Informe mensual de desarrollos dados de alta por el equipo de calidad de software del Implementador. Desarrollo de la estrategia de migración de acuerdo con las fuentes disponibles, las actividades a realizar, cronograma, herramientas y método para la migración de datos de las fuentes disponibles a los repositorios de las nuevas aplicaciones. | Supervisor Técnico |
19 | EJECUCIÓN | DESARROLLO | Acta de entrega de la aplicación para Sub-fase de pruebas | Esta entrega debe acompañarse del certificado de calidad de cumplimiento de los requisitos de la aplicación y los componentes de desarrollo a la medida de acuerdo con lo contratado. El entregable corresponde a los medios magnéticos con el instalador de los componentes del sistema de información, acompañados del instructivo y lista de chequeo para la instalación en el ambiente de pruebas. | Supervisor Técnico |
20 | EJECUCIÓN | DESARROLLO | Guion que contenga los casos de prueba funcionales y no funcionales | Validación para que exista mínimo un caso de prueba por cada requerimiento funcional y no funcional. | Supervisor Funcional Supervisor Técnico |
21 | EJECUCIÓN | DESARROLLO | Informe Pruebas Unitarias | Informe de resultados de pruebas unitarias funcionales y técnicas de acuerdo como se defina en la fase de planeación detallada del proyecto en común acuerdo con los supervisores del contrato. | Supervisor Funcional Supervisor Técnico |
22 | EJECUCIÓN | PRUEBAS | Informe de Migración de datos históricos y poblamientos de tablas | Informe de validación de estructura a migrar, Diagnostico de registros inconsistentes, Informe de resultado de la migración. | Supervisor Funcional Supervisor Técnico |
23 | EJECUCIÓN | PRUEBAS | Informe de Resultados de la Ejecución de Pruebas Integrales del sistema | Informe de resultados de pruebas integrales, defectos y aceptación de pruebas funcionales y técnicas. | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
24 | EJECUCIÓN | PRUEBAS | Manual funcional | Documentación (Word, pdf, html) y wiki incorporado en la aplicación, con la funcionalidad de la solución con el seguimiento paso a paso del proceso, los formularios presentados, las características de interfaz de usuario, uso de generalidades, validaciones definidas en cada formulario, flujos generales de los proceso de negocio, administración y parametrización funcional, informes y consultas, roles y funciones asociados a los perfiles de los usuarios, interacción con otros sistemas de información, normatividad aplicada, catálogo de servicios de la aplicación, inventario de respuestas frecuentes, control de versiones y versión final. Que incluye: Material de videos que pueden ser puestos a disposición de los usuarios para asistir capacitación funcional del sistema de información. Componentes de software para el acceso de ayudas en línea para el manejo o resolución de interrogantes de funcionalidad del sistema de información, interfaz de usuario, validaciones, consultas, reportes y administración de la información. | Supervisor Funcional |
25 | EJECUCIÓN | PRUEBAS | Manual técnico | Descripción de la arquitectura física y lógica, modelo de datos, descripción de la configuración de los parámetros relevantes, recomendaciones de administración de tablas básicas y paramétricas, administración de la configuración (Despliegue con TFS), procedimientos especiales, configuración para copias de respaldo, contactos del fabricante, descripción y alcance de la garantía, descripción y alcance del soporte técnico, contactos de soporte. Incluye: Manual y Guía de instalación: Descripción de la arquitectura de despliegue, información de versionamiento de componentes de aplicación y de software base requeridos para el despliegue, procedimientos de instalación, upgrades y reinstalación, consideraciones a tener en cuenta, control de versiones y versión final de la documentación. | Supervisor Técnico |
26 | EJECUCIÓN | PRUEBAS | Documento del Plan de salida en vivo | Descripción de las actividades para la salida en vivo, listas de chequeo de requisitos, lista de chequeo de alistamiento de componentes tecnológicos de aplicación e infraestructura, diseño de simulacro de salida en vivo. Plan para la instalación y configuración de la plataforma y sus componentes y de las soluciones en particular. Debe considerar los bloques de implementación indicados como hitos en el numeral anterior. | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
27 | EJECUCIÓN | PRUEBAS | Informe del inicio del despliegue de los productos aprobados por los supervisores y de acuerdo con el plan detallado del proyecto. | El despliegue del sistema se realizará por producción escalonada o gradual, en donde: Salida en Vivo 1 (Módulo o Proceso de: administración, correspondencia y expediente), de acuerdo como se defina en la fase de planeación detallada del proyecto en común acuerdo con los supervisores del contrato. | Supervisor Funcional Supervisor Técnico |
28 | EJECUCIÓN | DESPLIEGUE | Documentos de titularidad de las licencias de la aplicación y componentes adicionales a nombre de la Superintendencia Nacional de Salud. | Documento de licencia de uso, medios de instalación de software con el producto y sus componentes, manuales de instalación. La activación será a partir del recibo a satisfacción del sistema de información, en ambiente productivo. Nota: Los Manuales de Uso, serán ajustados una vez se implementen los desarrollos y parametrizaciones requeridas para cumplir con los requerimientos del sistema de información. El licenciamiento a entregar debe ser ilimitado (nombrados y concurrentes) de acuerdo con las condiciones del proyecto. | Supervisor Técnico |
29 | EJECUCIÓN | DESPLIEGUE | Informe de transferencia de conocimiento a usuarios finales y administradores técnicos y funcionales. | El documento contiene como mínimo: Contenido del entrenamiento Objetivos del entrenamiento Actividades realizadas Registro de Asistencia Evaluación del entrenamiento | Supervisor Funcional Supervisor Técnico |
30 | EJECUCIÓN | DESPLIEGUE | Certificación del ambiente de producción | Instalación y configuración de la plataforma, sus componentes y las soluciones en particular, en un ambiente productivo y un ambiente de pruebas que designe la entidad. | Supervisor Técnico |
31 | EJECUCIÓN | DESPLIEGUE | Acta que evidencie la Instalación o despliegue de software base y de solución | Acta con la verificación y validación del resultado del despliegue. | Supervisor Técnico |
32 | EJECUCIÓN | DESPLIEGUE | Informe de poblamiento de tablas básicas y parámetros | Resultados del poblamiento o cargue de información en los ambientes productivo y de pruebas que designe la entidad de las tablas paramétricas y de configuración. | Supervisor Técnico |
33 | EJECUCIÓN | DESPLIEGUE | Informe de resultados exitosos de la salida en vivo total del sistema de información. | Acta de revisión y validación de la lista de chequeo para salida en vivo e informe de salida en vivo. El informe debe estar acompañado del recibo a satisfacción del sistema de información, emitido por los supervisores técnicos y funcionales que certifican el cumplimiento de todos requerimientos funcionales y no funcionales del Sistema de Información. | Supervisor Técnico |
34 | EJECUCIÓN | ESTABILIZACIÓ N | Informe de Mejoras efectuadas durante el Servicio de acompañamiento para la estabilización del sistema de información | El sistema debe estar funcionando adecuadamente de acuerdo con las especificaciones funcionales y no funcionales contratadas, no debe haber ningún compromiso pendiente por cumplir, asociado al funcionamiento, diseño o características que se hayan definido para el sistema de información. El informe debe estar acompañado del recibo a satisfacción del sistema de información, emitido por los supervisores técnicos y funcionales que certifican el cumplimiento de todos | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
requerimientos funcionales y no funcionales del Sistema de Información. El contratista dispondrá en sitio de profesionales idóneos que atiendan y den solución a solicitudes, incidentes y/o problemas de índole de carácter técnico y funcional. Esta fase se desarrollará por un término no mayor a dos (2) meses o hasta el tiempo ofertado, contados a partir de la entrada en operación la totalidad del sistema de información, es decir, al finalizar la SUB-FASE de Despliegue. De estas actividades el contratista deberá presentar informes periódicos quincenales, en donde se evidencian los hallazgos y acciones tomadas al respecto. | |||||
35 | EJECUCIÓN | MONITOREO Y CONTROL | Informe Mensual de avance del proyecto para el comité directivo | El documento contiene: Indicadores de desempeño del proyecto, como % avance planeado, % real, desviación, % ejecución presupuesto. Matriz actualizada con el panorama de riesgos, entregables del periodo, asuntos más relevantes por atender a nivel directivo | Supervisor Funcional Supervisor Técnico |
36 | CIERRE | CIERRE | Medios de instalación de la aplicación, con la última personalización aprobada y puesta en producción y la documentación en última versión. | Que contiene: - Medio magnético (CD) de instalación del sistema de información implementado. - Medio Magnético (CD) Diseño, diagrama de entidad relación de las Bases de Datos - Documentación relacionada con el código fuente y la base de datos. - Código fuente de todos los componentes independientes, la personalización de la solución, el Reporteador y el porcentaje de desarrollo realizado. - Acta de recibido a satisfacción de los anteriores. | Supervisor Técnico |
37 | CIERRE | CIERRE | Informe de recibo a satisfacción de las funcionalidades puestas en producción por consumo de la bolsa de horas | Informe que será entregado en periodos mensuales, siempre y cuando se hayan realizado solicitudes en el periodo y estás se estén ejecutando, hasta que las funcionalidades solicitadas sean implementadas y recibidas a satisfacción por el supervisor funcional. Al final del contrato se entregará el informe que consolide todas las horas consumidas durante la ejecución del contrato. | Supervisor Funcional Supervisor Técnico |
38 | CIERRE | CIERRE | Informe final de cierre | Que contiene: - Informe de Lecciones aprendidas del proyecto. -Informe Talleres de Refuerzo (perfeccionar el cambio). - Informe que consolida la ejecución de actividades realizadas en la ejecución del contrato. - Medio magnético (CD) que contiene todos los documentos entregables en versión final, todas las actas generadas en el contrato debidamente inventariadas y los recibos a satisfacción del sistema implementado firmados por los supervisores. (3 copias del medio magnético). - Estado financiero del contrato (pagos realizados y pagos pendientes) con el debido soporte. | Supervisor Funcional Supervisor Técnico |
ID DEL ENTREGABL E | FASE | SUB-FASE | ENTREGABLE | CONSIDERACIONES DE ACEPTACIÓN MÍNIMAS | RESPONSABLE DEL RECIBO A SATISFACCIÓN |
- Medios de instalación de todas las aplicaciones implementados en versión final instalada. |
14. ACUERDOS DE NIVELES DE SERVICIO
El modelo de Acuerdo de Nivel de Servicios (Service Level Agreement, SLA) consiste en un acuerdo entre las partes en donde se estipulan los niveles de un servicio en función de una serie de parámetros objetivos, que mitigan el riesgo de incumplimiento por parte del contratista, en la medida que se hace un seguimiento mensual que alerta oportunamente al equipo de proyecto.
En consideración de lo anterior para la presente contratación se definen los indicadores de: i) Oportunidad y calidad en los entregables ii) Calidad en el funcionamiento del producto software en pruebas de aceptación iii) Calidad en el funcionamiento del producto software en Despliegue y estabilización.
Para efectos de cuantificar las penalizaciones correspondientes a la oportunidad de entrega de los entregables, el contratista deberá entregar al supervisor técnico el valor de cada entregable (consecuente con el valor ofertado en la propuesta económica para cada hito).
En la siguiente tabla se relaciona el momento de aplicación de cada uno de los ANS, según las fases del proyecto:
Fases del Proyecto Factor de Calidad | Inicio | Planeación | Análisis | Diseño | Desarrollo | Pruebas | Despliegue/ Implementación | Estabilización |
1. Oportuni dad y calidad en los entregables | x | x | x | x | x | x | x | x |
2. Calidad en el funcionamiento del producto software en Subfase de pruebas de aceptación | x | |||||||
3. Calidad en el funcionamiento del producto software en Subfase de Despliegue y Estabilización | x | x |
Tabla ANS por Fases del Proyecto
14.1 Oportunidad y calidad en los entregables
En el cronograma del proyecto el contratista deberá indicar las fechas de entrega para cada entregable de acuerdo con las fases y sub-fases definidas en el contrato, fechas sobre las cuales este indicador verificará el cumplimiento de entrega en el tiempo establecido, y atendiendo las siguientes características:
La fecha de entrega a considerar para cumplimiento de este ANS: Será tomada del recibido a satisfacción de cada uno de los entregables.
Frecuencia de la medición: Mensual
Fases en la que aplica: Todas (Inicio, Planeación, Ejecución, Monitoreo y control y cierre).
Evidencia: Recibos a satisfacción por parte del supervisor.
Fórmula para el cálculo:
Nro. Total de entregables recibidos a satisfacción según cronograma de plan de proyecto / Nro. Total de entregables planeados para el periodo |
Nota de la fórmula: En caso de existir entregables pendientes de periodos anteriores, éstos se sumarán en el denominador de la fórmula de éste indicador |
Interpretación:
o Si el resultado es igual o mayor a 90%, hay cumplimiento del Factor de calidad, por ende, no hay penalización.
o Si el resultado es menor a 90%, se penalizará el pago de los entregables del periodo, de la siguiente forma:
Resultado Obtenido de la fórmula | Porcentaje de penalización |
Entre el 70% y el 89.99%: | Penalización del 5% sobre el valor de los entregables no recibidos a satisfacción en el periodo |
Inferior del 70%: | Penalización del 7% sobre el valor de los entregables no recibidos a satisfacción en el periodo. |
Si se presenta penalización del 7% durante dos meses, el supervisor dará traslado al ordenador del gasto de la Supersalud para iniciar un proceso sancionatorio acorde con lo previsto contractualmente. | |
14.2 Calidad en el funcionamiento del producto software en Sub-fase de pruebas de aceptación.
La calidad será medida como el conjunto de propiedades o características inherentes a los módulos del software suministrado, para satisfacer los requerimientos solicitados por la entidad.
- El cumplimiento del nivel de calidad será sobre la correcta operación de las funcionalidades agrupadas por módulos, de acuerdo con el diseño aprobado para el sistema de información.
- En consecuencia, el contratista deberá, una vez finalizado y aprobado el diseño, entregar al supervisor técnico el valor de cada módulo a desarrollar (consecuente con el valor ofertado en la propuesta económica) para el sistema, dicho valor será la base para la medición de los indicadores de: Calidad en el funcionamiento del producto software en Sub-fase de pruebas de aceptación. Y calidad en el funcionamiento del producto software en Despliegue y estabilización.
- Entiéndase defectos en el presente capítulo, aquellas fallas que impidan realizar la operación normal de la funcionalidad solicitada.
Frecuencia: Mensual una vez se inicie la entrega de productos de software a la fase de Pruebas de aceptación.
Fases: Este indicador se medirá en la Sub-fase de: pruebas.
Evidencia: Informe de resultados de pruebas, defectos y aceptación de pruebas funcionales.
Fórmula de Cálculo: teniendo en cuenta la cantidad de defectos detectados, se identifica el porcentaje de penalización
Cantidad de defectos encontrados | % de penalización |
De 5 a 10 defectos: | 5% |
De 11 a 15 defectos: | 10% |
Más de 16 defectos: | 16% |
Si se presenta penalización del 16% durante dos meses consecutivos, el supervisor dará traslado al ordenador del gasto de la Supersalud para iniciar un proceso sancionatorio acorde con lo previsto contractualmente. | |
Seguido de lo anterior se calcula la siguiente fórmula:
% de Penalización x valor del módulo
Interpretación: Si el número de defectos es entre 5 y 10 el porcentaje a penalizar es el 5% del valor del módulo al que se realizaron las pruebas; Si el número de defectos es entre 11 y 15 el porcentaje a penalizar es el 10% del valor del módulo al que se realizaron las pruebas y Si el número de defectos es igual o superior a 16, el porcentaje a penalizar es el 16% del valor del módulo al que se realizaron las pruebas.
14.3 Calidad en el funcionamiento del producto software en Despliegue y estabilización:
La calidad será medida como el conjunto de propiedades o características inherentes a los módulos del software suministrado, para satisfacer los requerimientos solicitados por la entidad.
- El cumplimiento del nivel de calidad será sobre la correcta operación de las funcionalidades agrupadas por módulos, de acuerdo con el diseño aprobado para el sistema de información.
- Entiéndase defectos en el presente capítulo, aquellas fallas que impidan realizar la operación normal de la funcionalidad solicitada.
Frecuencia: Mensual por módulo de la aplicación durante el mes de despliegue y estabilización.
Fases: Este indicador se medirá en la Sub-fase de Despliegue y estabilización
Evidencia: Informe de eventos de fallo o error de funcionalidades en el sistema de información, durante las Sub-fases de Despliegue y estabilización.
Fórmula de Cálculo: teniendo en cuenta la cantidad de defectos detectados en despliegue y estabilización, se identifica el porcentaje de penalización
Cantidad de defectos encontrados | % de penalización |
De 1 a 3 defectos: | 10% |
Más de 4 defectos: | 15% |
Si se presenta penalización del 16% durante dos meses consecutivos, el supervisor dará traslado al ordenador del gasto de la Supersalud para iniciar un proceso sancionatorio acorde con lo previsto contractualmente. | |
Seguido de lo anterior se calcula la siguiente fórmula:
% de Penalización x valor del módulo
Interpretación: Si el número de defectos es entre 1 y 3 el porcentaje a penalizar es el 10% del valor del módulo y si el número de defectos es igual o superior a 4, el porcentaje a penalizar es el 15% del valor del módulo.
NOTAS QUE APLICAN PARA TODOS LOS ACUERDOS DE NIVELES DE SERVICIOS:
Las penalizaciones serán contabilizadas en periodos mensuales, la cuales serán acumuladas progresivamente, para ser descontadas de la facturación del hito de pago siguiente.
El valor base de los cálculos para la liquidación de descuentos, por concepto de incumplimiento de ANS, será sobre el valor antes de IVA.
15. SOPORTE y GARANTÍA
El tiempo de soporte y garantía para los productos contratados que incluyen los componentes licenciados, será de 12 meses, contados a partir del recibo a satisfacción del Sistema de Información, tanto para el licenciamiento adquirido, como para las configuraciones y desarrollos realizados.
El soporte y garantía debe cubrir el Sistema de información (componentes funcionales y no funcionales) implementado por el contratista, por defectos de fabricación, parametrización, implementación o por defectos en el código que ocasione mal funcionamiento, en caso de presentarse, el contratista estará obligado a corregir los errores de diseño, o programación, entendiéndose como corrección al diseño de componentes o los cambios de código fuente a los programas que conforman la aplicación y las actividades de implementación y despliegue que se requieran, sin ningún costo adicional para la entidad, proporcionando segundo y tercer nivel de escalamiento según lo requiera el caso, hasta dar solución al problema.
No estarán cubiertos por la garantía, los problemas ocasionados por causas externas al sistema de información, como problemas eléctricos, mal funcionamiento del Hardware, virus en el servidor, corrupción de información, problemas de comunicaciones, entre otros. Para estos casos la entidad será responsable de asumir los costos de reinstalar y restaurar la aplicación y los respaldos si es del caso.
Para solicitar la garantía del producto, la entidad empleará el procedimiento así:
- El usuario describirá el defecto o incidente presentado en el sistema de información y se reportará a través de la mesa de ayuda de la entidad, incluyendo la información detallada que tenga disponible.
- Las solicitudes de los usuarios serán recibidas en primera instancia por la mesa de ayuda de la entidad, la cual se encargará de tipificar la solicitud y direccionarla al contratista.
- El contratista procederá a realizar el diagnóstico y plan de solución, especificando los requerimientos y detalles necesarios para ejecutar el plan.
- El contratista implementará el plan con acompañamiento y verificación de la Supersalud hasta la solución del mismo.
- La garantía debe ofrecer soporte presencial con disposición mínimo de dos (2) personas de tiempo completo (8 horas diarias), Durante mínimo tres meses correspondientes a la etapa de estabilización, para este servicio las herramientas de trabajo serán provistas por el contratista.
Horarios de Atención Establecidos para el Soporte y garantía:
El servicio de Xxxxxxx y garantía deberá ser ofrecido en jornada de 7x24 para la atención y solución a requerimientos, incidentes y solicitudes.
Dentro de las actividades de soporte el proveedor deberá incluir ajustes y mejoras a la documentación funcional y técnica. Estos documentos deben además ser publicados en un portal Web para la consulta permanente de los usuarios (ayudas en línea).
Para la prestación del servicio de Soporte Técnico el contratista deberá disponer para la Supersalud de:
- Una mesa de ayuda que presente como mínimo los siguientes medios de comunicación: correo electrónico, chat, telefónico.
- Envío mensual y/o cuando la entidad requiera reporte de las incidencias y su estado, en donde se evidencie el soporte realizado, incluyendo como mínimo el usuario que reporta, el número de servicio asignado, el problema presentado, el sistema de información entregado y el tiempo de solución. El reporte mencionado deberá acompañarse de recomendaciones tendientes a solucionar incidentes o problemas recurrentes que se presenten e indicadores de gestión del servicio.
- Deberá poner a disposición del sistema una base de conocimiento donde los diferentes tipos de usuarios puedan encontrar respuestas a problemas presentados con el sistema. Esta base de conocimiento deberá enriquecerse con los problemas y soluciones encontrados durante la ejecución de este contrato, Al finalizar el contrato esta base de datos debe ser entregada a la entidad.
Niveles de servicio del Servicio de Soporte y garantía
El servicio ofrecido deberá observar los siguientes acuerdos de niveles de servicio mínimos de conformidad con el proyecto y los niveles de prioridad. La forma de establecer niveles de priorización debe ser incluidos en la metodología del proveedor:
PRIORIDAD | TIEMPO MÁXIMO DE SOLUCIÓN |
Alta | Dos (2) Horas |
Media | Ocho (8) Horas |
Baja | Veinticuatro (24) Horas |
Niveles de Clasificación de las Prioridades
La prioridad se establecerá de acuerdo con el impacto que la demora en la acción correctiva pueda generar en el servicio soportado por el sistema de información y en cada una de las actividades relacionadas con cada proceso.
Prioridad Alta: La atención de la incidencia puede afectar procesos que se encuentran delimitados en el tiempo, la inadecuada atención de esta prioridad puede acarrear a la entidad multas o el no cumplimiento de términos normativos x xx xxx, moratorias, sanciones por incumplimiento y/o afectación total de la prestación del servicio del sistema de información en particular.
a) Cuando los usuarios no pueden ingresar o utilizar la aplicación contratada.
b) Cuando se afecte la prestación de servicios a clientes externos de la entidad.
c) Cuando se identifiquen problemas de seguridad de la información.
d) Cuando se identifiquen inconsistencias de la información por causales técnicas del sistema.
Prioridad Media: En este nivel se clasifican aquellas incidencias relacionadas con el buen funcionamiento de los procesos de gestión soportados por el sistema de información, que son base o previos a la finalización del ciclo de vida de un proceso de gestión, la falta oportuna de atención a este tipo de prioridades puede generar retrasos importantes en la ejecución de los procesos de gestión y eventuales requerimientos de entes de control, además de la posibilidad de afectar la oportuna prestación del servicio soportado por el sistema de información en particular.
a) Cuando el sistema opera con restricciones que impiden completar la operación de negocio que define el caso de uso.
Prioridad Baja: Aquellas incidencias que no afectan procesos delimitados por el tiempo ni están relacionadas con el buen funcionamiento de los procesos de gestión. La atención para este tipo de prioridad da una espera más amplia frente a las prioridades alta y media.
a) No se encuentran disponibles algunas funciones o componentes del sistema, que genera un impacto mínimo para los usuarios del sistema.
b) Cuando no obstante las limitaciones, el sistema permite completar la operación de negocio.
c) Se refiere a un mal funcionamiento de la interfaz de usuario, que no impide la correcta ejecución del sistema.
d) Cuando hay inconsistencias en la imagen diseñada en la aplicación y documentos que se elaboran en la misma.
16. GLOSARIO
- .NET: framework de Microsoft que hace un énfasis en la transparencia de redes, con independencia de plataforma de hardware y que permita un rápido desarrollo de aplicaciones.
- APIS: interfaz de programación de aplicaciones.
- Archivo: conjunto de documentos, sea cual fuere su fecha, forma y soporte material, acumulados en un proceso natural por una persona o entidad pública privada, en el transcurso de su gestión, conservados respetando aquel orden para servir como testimonio e información a la persona o institución que los produce y los ciudadanos, o como fuentes de historia. También se puede entender como la institución que está al servicio de la gestión administrativa, la investigación, la información y la cultura.
- Archivo Central: en el que se agrupan los documentos transferidos por los distintos archivos de gestión de la entidad respectiva, cuya consulta no es tan frecuente pero siguen teniendo vigencia y son objeto de consulta por las propias oficinas y particulares en general.
- Archivo de Gestión: comprende toda la documentación que es sometida a continua utilización y consulta administrativa por las oficinas productoras u otras que la soliciten. Su circulación o trámite se realiza para dar respuesta o solución de los asuntos iniciados.
- Archivo Histórico: es aquel que se transfiere desde el Archivo Central los documentos de Archivo de documentación permanente.
- Archivo Total: concepto que hace referencia al proceso integral de los documentos en su ciclo vital.
- Backup: Copia de seguridad o copia de respaldo.
- BI: Business Intelligence.
- BPM: Business Process Management.
- BPMN: Business Process Model and Notation.
- CAdES: CMS Advanced Electronic Signatures
- Clasificación: operación archivística que consiste en el establecimiento de las categorías o grupos que reflejan la estructura jerárquica del fondo. Es el primer paso del proceso de organización.
- CMMi: Capability Maturity Model Integration.
- Documento de Archivo: Registro de información producida o recibida por una entidad pública o privada en razón de sus actividades o funciones.
- Documento Electrónico de Archivo: Registro de la información generada, recibida, almacenada, y comunicada por medios electrónicos, que permanece en estos medios durante su ciclo vital; es producida
por una persona o entidad en razón de sus actividades y debe ser tratada conforme a los principios y procesos archivísticos.
- Documento Original: es la fuente primaria de información con todos los rasgos y características que permiten que permitan garantizar su autenticidad e integridad.
- Estabilización: Es la sub-fase en la cual se realiza un monitoreo permanente al sistema de información para identificar oportunidades de mejora y/o ajustes que después de la puesta en producción sean necesarios para el afinamiento de los requerimientos funcionales y no funcionales del sistema.
- ESB: Enterprise Service Bus, en español traduce Bus empresarial de servicios.
- Estándar WS-I: Web Services Interoperability – Interoperabilidad de Servicios Web
- Etiquetas RFID: son autoadhesivas y se caracterizan por su flexibilidad, permiten conocer la situación de un documento y realizar su seguimiento en tiempo real.
- Expediente: conjunto de documentos relacionados con un asunto que constituya una unidad archivística, Unidad documental formada por el conjunto de documentos generados orgánica y funcionalmente por una oficina o dependencia productora en la resolución un mismo asunto.
- Filesystem: Sistema de archivos.
- Firma electrónica de larga duración o Firma digital longeva: Consiste en una firma electrónica dotada de validez a lo largo del tiempo.
- Folio: Hoja de libro, de cuaderno o de expediente, al que corresponde dos páginas, número que indica el orden consecutivo de las hojas que contiene un libro, folleto, revista.
- GAC: Grupo de Archivo y Correspondencia.
- Gel-XML: Es el estándar definido por el Estado Colombiano para intercambiar información entre organizaciones, facilitando el entendimiento de los involucrados en los procesos de intercambio de información.
- Gestión Documental: conjunto de actividades administrativas y técnicas pendientes a la planificación manejo y organización da la documentación producida y recibida por las entidades, desde su origen hasta su destino final, con el objeto de facilitar su utilización y conservación.
- IREB: Comité Internacional de Ingeniería de Requisitos (IREB eV)
- LAN: Red de área local.
- LDAP (Lightweight Directory Access Protocol): Protocolo Ligero/Simplificado de Acceso a Directorios.
- Microsoft Biztalk: plataforma de integración de procesos de negocio.
- OCR: Reconocimiento Óptico de Caracteres.
- Ordenación: Operación archivística realizada dentro del proceso de organización que consiste en establecer secuencias naturales cronológicas y/o alfabéticas, dentro de las categorías o grupos definidos en la clasificación.
- Organización: Proceso que, mediante las etapas de clasificación y ordenación, aplica las conclusiones establecidas en la fase de identificación a la estructura de un fondo.
- OWASP (Open Web Application Security Project): Proyecto abierto de seguridad de aplicaciones web.
- Patrimonio Documental: Conjunto de documentos conservados por su valor histórico o cultural.
- PAdES: PDF Advanced Electronic Signatures.
- PKCS#11: Public-Key Cryptography Standards.
- PPQA: Aseguramiento de calidad de proceso y producto.
- Selección documental: Es un proceso técnico por el cual se establece el tiempo en que los documentos de archivo sirven a sus diferentes fines.
- Serie Documental: Conjunto de tipos documentales de estructura y contenido homogéneos, emanados de un mismo órgano o sujeto productor como consecuencia del ejercicio de sus funciones específicas.
- SGDE: Sistema de Gestión de Documentos Electrónicos.
- SGDE-A: Sistema de Gestión de Documentos Electrónicos de Archivo.
- SGSSS: Sistema General de Seguridad Social en Salud.
- SharePoint: plataforma de colaboración empresarial.
- SISTEMA DE INFORMACIÓN: Corresponde al grupo de componentes de software, que se implementarán para cada uno de los procesos objetos del contrato.
- SISTEMA DE INSPECCIÓN, VIGILANCIA Y CONTROL: Conjunto de normas, agentes, y procesos articulados entre sí, el cual estará en cabeza de la Superintendencia Nacional de Salud de acuerdo con sus competencias constitucionales y legales.
- SISTEMA GENERAL DE SEGURIDAD SOCIAL EN SALUD: Es el conjunto de instituciones, normas y procedimientos, de que disponen la persona y la comunidad para gozar de una calidad de vida, mediante el cumplimiento progresivo de los planes y programas que el Estado y la sociedad desarrollen para proporcional la cobertura integral de las contingencias que menoscaban la salud de los habitantes del territorio nacional, con el fin de lograr el bienestar individual y colectivo.
- SNS: Superintendencia Nacional de Salud.
- SOA: Service Oriented Architecture.
- Soporte Documental: Medios en los cuales se contiene la información, según los materiales empleados.
- Subserie Documental: Conjunto de unidades documentales que forman parte de una serie, identificadas de forma separada de ésta por su contenido y sus características específicas.
- Tabla de Retención Documental: Listado de series o tipos documentales a los cuales se asigna el tiempo de permanencia en cada etapa de su ciclo vital, así como su destino una vez finalizada su vigencia administrativa, legal o fiscal.
- Tabla de valoración documental: Listado de asuntos o series documentales a los cuales se asigna un tiempo de permanencia en el archivo central, así como una disposición final.
- Tesauros del sistema de gestión documental: es la lista de palabras o términos controlados empleados para representar conceptos.
- Time stamping: Es el estampado cronológico que se le coloca a los documentos y consiste en una secuencia de caracteres que denotan la hora y fecha (o alguna de las) en la/s que ocurrió determinado evento.
- Tipo documental: Unidad documental simple originada en una actividad administrativa, con diagramación, formato y contenido distintivos que sirven como elementos para clasificarla, describirla y asignarle categoría diplomática.
- Transferencia de archivos: Remesa de los documentos del archivo administrativo al intermedio o central y de este al histórico de conformidad con las tablas de retención adoptadas.
- Unidad Documental: es la pieza mínima que reúne todas las características necesarias para ser considerada documento. Pueden se unidades documentales entre otras, u acta un oficio, un informe.
- VAL: La Validación (Pruebas funcionales y no funcionales)
- Valor Administrativo: el que contiene una serie o subserie documental, para la entidad productora, relacionado al trámite o asunto que motivo su creación, para responder a una necesidad administrativa mientras dure su trámite siendo indispensables por su utilidad referencial para la planeación y toma de decisiones.
- Valor Documental: es el que posee un documento para la administración que lo originó o para aquella que se le sucede como testimonio de sus procedimientos y/o actividades.
- W3C: World Wide Web Consortium
- WAN: Red de área amplia
- WCAG2.0: Web Content Accessibility Guidelines
- WIKI: nombre que recibe un sitio web cuyas páginas pueden ser editadas directamente desde el navegador, donde los usuarios crean, modifican o eliminan contenidos que, generalmente, comparten.
- XADES (XML Advanced Electronic Signatures): Firma electrónica avanzada XML.
- XPDL (XML Process Definition Language): es un lenguaje para la definición de un Flujo de trabajo.
Por LA SUPERINTEDENCIA, Por EL CONTRATISTA,
XXXXX XXXXXX XXXXXX XXXXXX | XXXXX XXXXXX XXXXX XXXXXX |
Visto bueno técnico:
Xxxxxxxxx Xxxxxx Xxxxxxxx
Jefe de la Oficina de Tecnologías de la Información.
Xxxx Xxxxxx Xxxxxxx Xxxxxx
Coordinador del Grupo de Gestión Documental
Revisó
Xxxxx Xxxx Xxxxxx
Coordinador del Grupo de Arquitectura TI
Xxxxx Xxxxxxxx Xxxxxxx Xxxxxxxxx
Profesional Especializada Grupo de Gestión Documental