DIRECTIVA DE CONTRATACIÓN PÚBLICA N° 8
DIRECTIVA DE CONTRATACIÓN PÚBLICA N° 8
INSTRUCCIONES PARA LA CONTRATACIÓN DE BIENES Y SERVICIOS RELACIONADOS CON TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES
Contenido
OBJETIVO DE LA DIRECTIVA 3
PAUTAS PARA CONTRATACIÓN DE BIENES Y SERVICIOS RELACIONADOS CON TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES 3
1.1 Preparación de la Licitación. 3
1.1.1 Análisis de la Necesidad y Alternativas de Solución. 3
1.1.2 Consulta a la Industria o RFI (Request for Information). 4
1.1.3 Cubicación del Proyecto. 5
1.2 Bases de Licitación. 6
1.2.1. Preparación de las Bases Técnicas 6
1.2.1.1. Descripción del Requerimiento 7
1.2.1.2. Niveles de Servicio (SLAs) 7
1.2.2. Preparación de las Bases Administrativas 8
1.2.2.1. Documentación Administrativa 8
1.2.2.2. Utilización de un Presupuesto de Referencia 9
1.2.2.3. Reunión Informativa 9
1.2.2.4. Criterios de Evaluación 9
1.2.2.5. Comisión de Evaluación 10
1.2.2.6. Cláusulas sobre Propiedad Intelectual 11
1.2.2.7. Cláusulas sobre Responsabilidad 13
1.2.2.8. Cláusulas sobre el Control de Cambios y Contratos Complementarios 14
1.2.2.9. Cláusulas sobre Término Anticipado del Contrato 15
1.2.2.10. Cláusulas sobre Cierre del Contrato 15
1.3. Cierre del Proceso de Licitación 16
1.4. Gestión del Contrato. 17
DIRECTIVA DE CONTRATACIÓN PÚBLICA N° 8
INSTRUCCIONES PARA LA CONTRATACIÓN DE BIENES Y SERVICIOS RELACIONADOS CON TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES
Las Directivas de Contratación son instrucciones para las distintas etapas de los procesos de compras y contratación que realizan los organismos públicos adscritos a la Ley N° 19.886. Se formulan de acuerdo a la normativa vigente y a las políticas de Gobierno en la materia.
A continuación se presentan directivas sobre la contratación de bienes y servicios relacionados con tecnologías de la información y comunicaciones.
OBJETIVO DE LA DIRECTIVA
El objetivo de esta directiva es entregar pautas y lineamientos a los organismos públicos regidos por la Ley N°19.886 para la contratación de bienes y servicios relacionados con tecnologías de la información y comunicaciones, tales como: servicios de desarrollo de software, de operación de sistemas, de adquisición de hardware o software, de análisis de datos, plataforma de datos, de hosting o housing, de externalización, o de optimización y automatización de procesos de gestión, entre otros.
PAUTAS PARA CONTRATACIÓN DE BIENES Y SERVICIOS RELACIONADOS CON TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIONES
1.1 Preparación de la Licitación.
1.1.1 Análisis de la Necesidad y Alternativas de Solución.
Una vez que exista claridad respecto de la necesidad o requerimiento que se quiere abordar, la entidad debe identificar y evaluar distintas alternativas de solución. Este proceso debe incorporar entre otros aspectos:
• Análisis de elementos conceptuales básicos, por ejemplo, análisis de modelos operacionales alternativos, definir cuánta externalización se requiere (considerar que la externalización ordena la operación y permite al organismo contratante concentrase en su negocio principal, pero internaliza parte de los riesgos del operador externo), acotar quienes serán los principales usuarios, definir a qué plazo se espera tener el problema resuelto, etc.
• Análisis de elementos de gestión, entre otros elementos se deberá revisar si la institución tiene las competencias internas para la realización del proyecto y qué tipo de apoyo externo será necesario incorporar.
• Análisis de restricciones respecto de alternativas tecnológicas, se deberá considerar si existen sistemas anteriores y qué restricciones imponen éstos a los servicios que se contratarán, entre otros puntos.
• Primera aproximación a los costos de contratación, una posibilidad para aproximarse a los costos es revisar experiencias similares de otros organismos públicos en ChileCompra.
• Análisis y definición de alcance, esto implica definir bien qué se está contratando y qué no. Por ejemplo, si se está contratando el desarrollo de un sitio web que tendrá una sección en inglés, deberá quedar definido si está dentro o fuera del alcance del proyecto la traducción de documentos. O si se está contratando la operación de un sistema, deberá definirse si las licencias para que opere el sistema serán provistas por el contratante o por el operador. Esta definición es particularmente importante, puesto que los proyectos con alcance difuso pueden tener problemas serios durante la implementación.
El producto debería ser un documento de proyecto que contenga, a lo menos, una descripción del problema a resolver, los servicios a contratar, los plazos disponibles y las principales etapas del proyecto.
1.1.2 Consulta a la Industria o RFI (Request for Information).
El análisis realizado en la etapa anterior, especialmente en casos de alto valor e impacto, debe ser respaldado con la incorporación de la experiencia y conocimiento de la industria TIC. Por lo tanto, se recomienda a las entidades realizar una consulta amplia, estructurada y formal a los potenciales proveedores. Este proceso también se conoce como request for information (“RFI”). En general, para el desarrollo de un RFI se recomienda considerar lo siguiente:
a) Relación con la posterior licitación: La entidad podrá optar por mecanismos que generen incentivos a las empresas para participar en el RFI. Así, por ejemplo, podrá establecer un criterio de evaluación que otorgue puntaje o un aumento porcentual de éste, para los oferentes que hubiesen participado en el RFI. De este modo, se incentiva a las empresas a colaborar con la entidad en el RFI, sin que esta participación signifique una barrera de entrada al proceso licitatorio.
b) Establecer con precisión los puntos sobre los que necesita que la industria aporte información: Un RFI puede incorporar consultas sobre aspectos técnicos, comerciales o de
negocio. Por ejemplo, un RFI puede consultar sobre alternativas para solucionar un problema o sobre las posibles reglas para evaluar las propuestas.
c) Establecer el documento de RFI. Este documento se estructura a partir de las definiciones del proyecto, incluye las preguntas que se están formulando a la industria y las reglas de la consulta. Entre estas reglas, se sugiere incluir el plazo para recibir respuestas y los medios y formatos a través de las cuales éstas se recibirán. Se recomienda también, que el documento contenga las cláusulas esenciales del contrato definitivo, tales como: plazo, causales de término, forma y cálculo de multas, control de cambios, etc., de forma tal de entregar la mayor información posible a la industria, para que a su vez ésta pueda hacer las consultas y observaciones con mayor precisión.
d) Establecer la base de proveedores. Puede ser determinada mediante la utilización de los registros de ChileCompra o de asociaciones gremiales, entre otras fuentes.
e) Convocatoria al RFI. El proceso debe ser difundido ampliamente. Al menos publique el documento de RFI en la página web del organismo público y distribúyalo a la base de proveedores y las asociaciones gremiales.
f) Reunión de RFI. Considere como parte del proceso una o más reuniones de discusión del documento de RFI. En estas sesiones se espera que las empresas que respondan a la convocatoria se reúnan con el responsable del proyecto con el objeto de discutir las consultas formuladas en el RFI.
1.1.3 Cubicación del Proyecto.
Cubicar el proyecto significa establecer el costo estimado del proyecto a licitar. Para esto, es de extrema utilidad identificar en detalle las distintas actividades del proyecto y sus respectivos plazos. Esto le permitirá identificar los distintos recursos involucrados en estas actividades.
Estos recursos pueden ser entre otros: Tiempos por perfil profesional interno y externo, licencias para desarrollo, licencias de software (bases de datos, sistemas operativos, etc.), hardware (por ejemplo: discos duros, servidores, routers, etc.).
Identificados los recursos necesarios y utilizando la información que haya podido levantar en las distintas etapas del proyecto, asigne los costos respectivos. Considere costos específicos, por ejemplo, si necesita servidores de cierto tipo, utilice en la cubicación el valor de esos servidores y no de otros.
Finalmente revise si la cubicación realizada está alineada con el presupuesto disponible. En caso contrario deberá revisar el proyecto de manera de ajustarse a la disponibilidad presupuestaria.
1.2 Bases de Licitación.
Elabore las bases de licitación considerando todo lo investigado hasta el momento, y en la medida que haya generado buenos documentos en las etapas anteriores, utilícelos como apoyo a la redacción de las bases.
Dependiendo de los componentes del servicio licitado, prepare la licitación en varias líneas. Por ejemplo: infraestructura, software aplicativo y/o sistema operativo, comunicaciones, soporte, servicios conexos y otros. Esto permite contratar todos los componentes a un solo proveedor o a distintos proveedores, según la factibilidad técnica y las reglas que establezca la licitación.
Considere que en general, para este tipo de procesos es recomendable diseñar licitaciones en dos etapas, la primera técnica y la segunda económica. Esto permite evaluar en detalle la calidad técnica de las propuestas, sin sesgos originados por la oferta económica.
1.2.1. Preparación de las Bases Técnicas
Sin perjuicio del contenido específico de las bases técnicas, considere los siguientes elementos generales en su diseño:
a) Principio de neutralidad tecnológica: El Gobierno de Chile adhiere al principio de neutralidad tecnológica, lo que implica que no se debe dar preferencia a tecnología alguna, sino que se debe buscar en cada caso la mejor alternativa disponible en el mercado. Sin embargo, puede que en algunas circunstancias, existan razones fundadas para restringir las opciones a un cierto tipo de tecnologías, en este caso, los fundamentos deben quedar claramente establecidos en las bases.
b) Principio de no discriminación por utilización de formatos propietarios: De manera de permitir la participación del mayor número de proveedores en el proceso, se deberá evitar exigir formatos propietarios para la presentación de las ofertas de los proveedores. Por lo tanto, las bases de licitación deberán privilegiar la utilización de formatos interoperables como xml, txt o csv. Este principio es especialmente relevante para los archivos producto de aplicaciones de productividad personal como procesadores de texto u hojas de cálculo.
c) Estándares de seguridad: Los desarrollos deberán dar cumplimiento a las normativas existentes en materia de seguridad, en particular aquellas que tienen relación con el Decreto 83/2005 que aprueba la norma técnica para los órganos de la administración del Estado sobre seguridad y confidencialidad de los documentos electrónicos.1
d) Estándares de interoperabilidad y portabilidad: Deben especificarse estándares que aseguren interoperabilidad de los sistemas y portabilidad de las soluciones, de manera de asegurar el intercambio de información a través de estándares abiertos y de general aceptación por la industria. Como mínimo, se debe exigir el ajuste a las normas técnicas sobre interoperabilidad del documento electrónico contenidas en el Decreto Supremo N°
81 del 3 xx Xxxxx de 2004, que aprueba la norma técnica para los órganos de la administración del Estado sobre interoperabilidad de documentos electrónicos.2
1.2.1.1. Descripción del Requerimiento
Éste es el elemento más importante en las bases técnicas. Considere que mientras más precisas sean las especificaciones técnicas del requerimiento, las ofertas serán más ajustadas a mercado y a la expectativa del contratante. En este sentido deje claramente reflejado en los documentos de licitación los servicios requeridos y el alcance del proyecto. Algunos elementos a considerar para esta sección del documento son:
• Descripción del organismo contratante
• Descripciones del entorno del problema
• Descripciones de la solución o servicio requerido
• SLAs definidos
• Alcance del servicio requerido
• Recursos institucionales disponibles
• Principales restricciones
• Sistemas complementarios
• Principales hitos o plazos del proyecto
• Presupuesto estimado
• Otros
Hacer especificaciones de detalle es complejo, sin embargo, no hacerlas puede implicar que durante el desarrollo del proyecto surjan problemas de interpretación de bases y contratos con el proveedor. Este tipo de problemas pueden ser significativos dependiendo del valor del proyecto.
1.2.1.2. Niveles de Servicio (SLAs)
En el caso que lo que se esté contratando sea un servicio (por ejemplo la externalización de la operación de un sistema), las bases técnicas deben especificar los niveles de servicio requeridos por su organización.
Estos niveles se refieren a aspectos operacionales del servicio contratado y pueden ser, por ejemplo, up time de aplicaciones, tiempo de respuesta frente a errores o tiempos de
proceso, entre otros. Las variables relevantes deben ser modeladas a través de indicadores y cada indicador debe tener asociado un estándar mínimo aceptable.
La identificación de los niveles de servicio es muy relevante, puesto que definirán el estándar de servicio de la solución durante toda la vigencia del servicio contratado. Se debe considerar, en todo caso, que mientras más exigente sean los niveles de servicio que se requieran, más alto será el precio del contrato.
Finalmente, considere en las propias bases de licitación y en el contrato respectivo, causales y mecanismos que permitan ajustar los niveles de servicio. Una causal puede ser por ejemplo, cambios tecnológicos o niveles de operacionales considerablemente distintos a los definidos originalmente producto de los cambios en el entorno.
Si los niveles de servicio constituyen una cláusula esencial del contrato definitivo y cuyo incumplimiento podría ocasionar el término unilateral del contrato, debe establecerse expresamente de forma tal de advertir a los proveedores de dicha circunstancia y evitar que se presenten aquellos proveedores que no podrán cumplir con esos niveles de servicio.
1.2.2. Preparación de las Bases Administrativas
Las bases administrativas permiten regular el proceso licitatorio y además constituyen elementos fundamentales para la redacción del posterior contrato de servicios. Las bases administrativas deben proteger los intereses del contratante, pero al mismo tiempo mantener todos los principios de la contratación pública. Algunos temas a considerar son los siguientes:
1.2.2.1. Documentación Administrativa
Corresponden al conjunto de antecedentes legales y administrativos que son parte de la oferta que hace el proveedor y que permiten acreditar elementos básicos para la validez de su propuesta. Por ejemplo, que el que oferta está facultado para hacerlo, o que la empresa existe.
Mientras más documentos solicita, más desincentivos tendrán los proveedores para participar en el proceso. Por lo tanto, se recomienda limitar al máximo la cantidad de documentos de oferta necesarios para participar en el proceso. Considere lo siguiente:
a) Si el proveedor está registrado en ChileProveedores, no es necesario solicitar documentos legales básicos, ni documentos para validar las habilidades de contratación con el Estado referidas en el artículo 92 del reglamento de la Ley de Compras Públicas. También deberá permitir que los proveedores no entreguen el resto de la documentación en formato físico si ésta ya ha sido incorporada a ChileProveedores.
b) Todos los documentos que reporten antecedentes que se mantienen inalterables por largos periodos de tiempo o que son intrínsecos a la condición o experiencia del proveedor,
por ejemplo los CVs de los socios de la empresa o la experiencia de la empresa, pueden ser solicitados como parte de la oferta. Sin embargo, explicite causales en las bases que permitan recibir antecedentes de este tipo durante el período de evaluación de las ofertas, hasta una fecha determinada antes de la adjudicación. Esto permite no rechazar ofertas por defectos meramente formales.
c) Finalmente, se debe considerar que la documentación solicitada será relevante sólo en la medida que permita validar ciertos atributos mínimos de las empresas oferentes. No se deben solicitar informes comerciales, financieros, del personal, certificaciones, etc., salvo que éstos sean fundamentales para la evaluación de la oferta y funcionales a los intereses del servicio.
1.2.2.2. Utilización de un Presupuesto de Referencia
Para la contratación de servicios intensivos en TIC, se recomienda explicitar en la licitación el presupuesto de referencia. La razón es que mediante el presupuesto se le entrega al mercado información valiosa sobre el alcance del proyecto. De esta manera las empresas podrán hacer mejores ofertas.
En vista de lo anterior, y puesto que la utilización de presupuestos de referencia tiende a definir el rango de precios de adjudicación, es muy importante que esté claramente definido el proyecto, y sobre todo muy bien cubicado. El presupuesto de referencia debe ser un valor consistente con el mercado.
1.2.2.3. Reunión Informativa
De modo de aclarar el sentido del proyecto y el alcance del mismo, se deben incorporar una o más reuniones informativas dentro del proceso licitatorio. Estas reuniones deberán ocurrir apenas publicadas las bases de licitación. Señale en las bases el lugar, fecha y hora en el que se desarrollarán las reuniones.
En esta instancia, el encargado de la licitación deberá presentar: el contexto, el alcance, los resultados esperados, el cronograma, los aspectos medulares de las bases y otros elementos que estime relevantes.
Sin perjuicio que puedan existir preguntas orales, se debe establecer que las respuestas formales a las consultas que puedan surgir como resultado de la reunión, así como de la lectura detenida de las bases, deberán ser realizadas por los canales formales en el sistema ChileCompra, durante la etapa de preguntas y respuestas de la licitación.
1.2.2.4. Criterios de Evaluación
Se deben establecer criterios de evaluación que sean lo más objetivos posibles. A continuación se presentan algunos criterios que pueden ser utilizados:
a) Calidad de la propuesta. Descripción detallada de la oferta, equipos de trabajo, plazos de ejecución, garantías de los productos, servicios complementarios, entre otros.
b) Calidad técnica de la solución ofrecida. Nivel de respuesta para el problema planteado, rendimiento esperado de la solución ofrecida, disponibilidad de soporte, entre otros.
c) Experiencia del equipo de trabajo. En proyectos TIC es especialmente relevante que el equipo de trabajo asignado al proyecto en la oferta sea calificado y con experiencia en los temas tecnológicos ofertados. Especialmente relevante es la experiencia del jefe de proyecto en soluciones similares. Se deben solicitar referencias que permitan evaluar la participación de los oferentes en proyectos similares.
d) Experiencia de la empresa. Al igual que el equipo de trabajo, la experiencia de la empresa es un indicador de la probabilidad de éxito del proyecto. Sin embargo, este punto es menos relevante que la experiencia del equipo de trabajo propuesto. Las experiencias similares deben comprobarse a través de medios fehacientes.
e) Certificaciones. En el caso que se considere relevante asignar puntaje por las certificaciones de la empresa o del equipo de trabajo, se deben considerar certificaciones como ISO, CMMi3 u otras similares. Se recomienda también la aceptación de otras certificaciones equivalentes.
Las certificaciones se podrán solicitar en la medida que no signifiquen un requisito mínimo que origine la aprobación o rechazo de una oferta, sino que simplemente sean ponderables dentro de los criterios de evaluación.
f) Satisfacción de clientes en proyectos similares. Se recomienda incluir en los criterios de evaluación encuestas a clientes de la empresa, donde se solicite evaluar la satisfacción con los resultados del servicio contratado.
g) Precio. Precio de las ofertas.
Para hacer más objetiva la evaluación, se recomienda definir pautas precisas para cada uno de los criterios. Estas pautas deberán ser parte de las bases de licitación. Respecto de la asignación de puntajes, esto dependerá del nivel de riesgo que se este dispuesto a asumir. Se recomienda concentrar la asignación de puntajes en los criterios de calidad de la solución técnica ofrecida y en el criterio de la experiencia del equipo de trabajo.
1.2.2.5. Comisión de Evaluación
Puesto que la evaluación de licitaciones intensivas en TIC pueden incluir elementos relativamente subjetivos, utilice comisiones evaluadoras. Esta comisión deberá utilizar las
3 Ver xxxx://xxx.xxx.xxx.xxx/xxxx/ y CMMI® for Acquisition (CMMI-ACQ)
pautas de evaluación que incorporen las bases. El trabajo de esta comisión deberá plasmarse en un informe detallado de evaluación. Este informe deberá venir suscrito por cada uno de los evaluadores.
Se recomienda que la comisión esté compuesta por personal técnico del organismo y expertos externos. Ellos deben ser independientes, desinteresados, imparciales y no representantes de ninguna tecnología o corriente doctrinaria particular. Por transparencia, una vez adjudicado el proceso, se deberán difundir los nombres de los evaluadores.
En licitaciones de alta complejidad se recomienda la contratación de expertos externos, tales como universidades u otros organismos técnicos validados por el mercado, para realizar una evaluación técnica especializada.
1.2.2.6. Cláusulas sobre Propiedad Intelectual
Cuando se encarga la producción de un programa computacional a un tercero, se debe regular expresamente a quién corresponde la titularidad de los derechos de propiedad intelectual. Es de vital importancia que al diseñar la licitación se analice el alcance del requerimiento en relación a este punto específico. Atendida la función del organismo público, también se debe regular la naturaleza de la información que se administra, los objetivos que se persiguen con el desarrollo del programa computacional, y la utilización futura que el organismo quiera hacer del software y sus códigos. En particular, se recomienda considerar las siguientes modalidades:
a) El Servicio Público compra un software o encarga su desarrollo a un tercero, donde la propiedad intelectual y todos los derechos que se derivan de la misma son exclusivos del organismo público. Se recomienda incluir cláusulas específicas en las bases de licitación que regulen claramente esta situación.
Estas cláusulas deben considerar que la propiedad intelectual del software radique en la institución pública, precisando la manera de entrega de los códigos fuente y de toda la información relevante asociada al desarrollo respectivo. La entrega de todos estos elementos al organismo público deberá ser realizada apenas el sistema esté instalado y antes del cierre del contrato. Además se deberá regular con claridad la entrega de las distintas actualizaciones que pueda sufrir el software con posterioridad a la primera entrega.
Asimismo, estas cláusulas deberán considerar las sanciones correspondientes en el caso que la empresa no cumpla con lo dispuesto en la sección anterior.
Finalmente, se recomienda incluir como cláusula, la obligación del desarrollador de entregar o eliminar completamente la información asociada a este desarrollo.
Por lo general, este enfoque sobre la propiedad intelectual será de mayor costo, debido a que el desarrollador del programa computacional no tendrá derecho alguno sobre el software, por lo que intentará maximizar su retorno a través de un precio mayor.
b) El Servicio Público encarga el desarrollo de un programa computacional o compra uno ya hecho a un tercero, donde la propiedad intelectual y los derechos que se derivan de la misma son del organismo público, sin perjuicio que se autoriza a la empresa a comercializar el producto. Se recomienda incluir cláusulas específicas en las bases de licitación que regulen claramente esta situación, precisando qué derechos corresponden a cada una de las partes.
En este caso se deberán considerar los mismos elementos que en la modalidad anterior, pero se deberán considerar además cláusulas específicas en las bases que regulen cómo se materializa la autorización de comercialización. Por ejemplo, esta autorización podrá tener un plazo determinado, podrá ser consultada caso a caso, podrá estar restringida a ciertos mercados específicos, podrá incluir el derecho para los organismos públicos a recibir sin costo actualizaciones y mejoras del software, entre otras.
Por lo general, esta solución es menos costosa que la anterior, pero puede generar mayor incertidumbre jurídica respecto a los derechos de cada parte, lo que puede terminar provocando potenciales conflictos.
c) El Servicio Público encarga el desarrollo de un programa computacional a un tercero en la modalidad de licencia de uso, conservando el desarrollador del programa computacional la propiedad intelectual del software. En este caso la institución pública recibe los programas en código objeto o ejecutable y las licencias respectivas y no el código fuente del programa computacional, que es el que permite realizar modificaciones al software a futuro. Se recomienda además solicitar al tercero el depósito en una notaría del código fuente, para el evento de requerir el acceso, en situaciones como: quiebra xxx xxxxxxx, discontinuidad del soporte por negativa de la empresa, desaparición de la empresa, etc. Si bien esta alternativa es la más restrictiva para el organismo público, suele ser la más económica.
En el caso que el desarrollo contratado sea en base a un software ya existente, usted deberá considerar las mismas alternativas anteriores en relación al producto final. Para esto deberá tomar la precaución de levantar un inventario de software al inicio del desarrollo, de manera de dejar claramente establecido el código de software original, recomendándose incluso, para mayor seguridad, que se exija en las bases que el código original sea depositado en una notaría.
d) Para todos los casos, deje claramente establecido el tratamiento de los up-grades o up- dates (actualizaciones y mejoras), en el sentido de entenderlos o no entenderlos incorporados al precio global de la solución contratada, regulando sólo los requisitos formales de su procedencia. Lo normal es que las actualizaciones y mejoras sean parte del proceso de licitación, ya sea que el precio se incluya en el precio total de la solución o se establezca por separado. No se recomienda dejar la negociación del precio de las actualizaciones y mejoras de una solución tecnológica para luego de cerrado el proceso de licitación.
1.2.2.7. Cláusulas sobre Responsabilidad
a) Responsabilidades: Con el fin de promover la mayor participación de oferentes y de evitar la traslación de riesgos en los precios, se recomienda incluir en las bases de licitación una referencia a las normas generales sobre responsabilidad establecidas en el Código Civil para los contratos bilaterales onerosos, esto es, responder de culpa leve. Se debe tener en cuenta las normas sobre responsabilidad sobre daños directos y previstos. Sin embargo, se debe considerar el nivel de riesgo asociado a problemas de mal funcionamiento de soluciones o servicios TIC contratados. En casos excepcionales y estando en riesgo la criticidad o continuidad del servicio, podrán solicitarse grados de responsabilidad mayor. Asimismo se recomienda definir en cada caso, la criticidad del servicio, la que dice relación, con el tipo y función pública.
Se recomienda a las entidades públicas establecer en las bases de licitación un monto máximo de perjuicios a indemnizar. Adicionalmente podrá ser materia que los oferentes propongan un monto máximo a indemnizar, el que será evaluado con pautas preestablecidas y objetivas.
b) Obligación de defensa, indemnización y continuidad: Se recomienda incluir una cláusula en que el proveedor asuma la responsabilidad para el caso en que alguna o todas las soluciones infrinjan derechos de propiedad intelectual o derechos de propiedad industrial. En esta misma línea, el proveedor se debe obligar a indemnizar a la entidad respectiva respecto de cualquier reclamo, demanda, querella o acción de cualquier clase que se genere por dicho concepto, incluyendo montos por indemnización, por suspensión de operaciones y gastos generados por concepto de reclamos o demandas que pudieren interponerse en contra de la entidad.
Durante el tiempo que dure algún conflicto sucedido, si la entidad fuere privada de utilizar una o más de las soluciones proporcionadas por el proveedor, el proveedor debe proveer con alternativas efectivas a la entidad para seguir operando, y todas esas alternativas deberán ser costeadas por el proveedor.
c) Garantías del producto o servicio: Al contratar productos o servicios intensivos en tecnologías de información, las garantías vigentes una vez cerrado el contrato son relevantes. Por tal motivo, las bases de licitación y el posterior contrato deberán considerar distintos tipos de garantías que resguarden al servicio de las situaciones más críticas que puedan ocurrir una vez concluidos los servicios contratados. Al menos se recomienda considerar las siguientes:
• En el caso de proyectos TIC, suele ocurrir que haya que realizar ajustes al desarrollo, debido a errores detectados una vez que entra en funcionamiento la solución. El período de garantía dependerá de la complejidad de la solución, pero se recomienda que sea superior a seis meses. Las reparaciones de los errores a los sistemas que se produzcan durante el período de garantía no deberán tener costo adicional para el contratante. Esto debe quedar claramente establecido en las
• Igualmente, el proveedor debe garantizar a la entidad pública que en el cumplimiento del contrato, no utilizará información confidencial, propiedad intelectual o propiedad industrial de terceros, sin la autorización de los correspondientes titulares, y que en el cumplimiento del contrato no infringirá derechos de propiedad intelectual o industrial de terceros.
d) Multas: Como en la licitación de cualquier proyecto o servicio se deben establecer en las bases de licitación multas y sanciones por atrasos en la ejecución de los servicios, o asociadas al no cumplimiento de niveles de servicio definidos, si corresponde.
Las multas por atraso o por incumplimiento deben ser claras, determinadas o determinables y además razonables a las cuantías de los contratos. Además, antes de imponerse una multa, se debe notificar al proveedor y otorgar un plazo para solucionar los incumplimientos comunicados. Es recomendable generar un protocolo de aplicación de multas que se anexe al contrato definitivo y que considere una instancia de revisión administrativa.
Pese a lo anterior, debe tener claro que mientras más multas tengan asociadas un proyecto, más caro resultará. Por lo tanto, definir las multas que asociará a los distintos incumplimientos que puedan ocurrir en el proyecto, dependerá de la evaluación del riesgo que exista a la hora de diseñar la licitación.
e) Garantía: De acuerdo a la Ley de Compras Públicas es obligación requerir garantías de seriedad de la oferta y de fiel y oportuno cumplimiento del contrato, cuando se trate de contrataciones iguales o superiores a UTM 1.000.
Ambas garantías deben ser fijadas en un monto que cumpla con la finalidad de ellas, sin desincentivar la participación de los oferentes al llamado de licitación.
La garantía de cumplimiento de contrato debe ser proporcional al monto del contrato y al valor del posible perjuicio para el servicio o terceros derivado del no cumplimiento del contrato. Para más detalles, remitirse a Directiva N° 7 sobre “Instrucciones para Uso de Garantías en Procesos de Compras”.
1.2.2.8. Cláusulas sobre el Control de Cambios y Contratos Complementarios
Cualquier proyecto complejo puede requerir contratos adicionales al contrato principal, de manera de cubrir posibles requerimientos no dimensionados en los términos de referencia originales. Sin embargo, este tipo de contratos pueden significar un cambio en las condiciones originales de la licitación y por lo tanto, no pueden ser ilimitados. En virtud de lo anterior, fije en las bases de licitación un porcentaje máximo para contratos complementarios o para los controles de cambio. El referido porcentaje debe estar en relación con el monto y naturaleza del contrato y/o complejidad del proyecto que se trate.
Para que el control de cambios pueda operar de manera transparente, las bases deberán solicitar que las ofertas incluyan valores unitarios para los servicios más susceptibles de ser modificados, por ejemplo, valor de horas de desarrollo.
Se recomienda fijar qué tipos de cambios o qué tipo de contratos complementarios al proyecto son aceptables o no. Por ejemplo, si se contrató desarrollo de software y no se consideró el diseño gráfico, el control de cambios podría incluir diseño gráfico. Pero si luego se pretende que el desarrollador opere los sistemas, resulta alejado del negocio licitado originalmente.
Si es titular de los derechos, entonces las bases deben establecer si el control de cambios es un derecho exclusivo para el proveedor, o si sólo es una opción para la entidad y en consecuencia, no la obliga a contratar estos cambios con dicho proveedor.
1.2.2.9. Cláusulas sobre Término Anticipado del Contrato
Se recomienda que las bases establezcan causales de término anticipado del contrato basadas en incumplimientos objetivos y demostrables, según la naturaleza del servicio contratado, considerándose previamente un plazo razonable para subsanar el eventual incumplimiento. Adicionalmente, se sugiere regular para estos casos, la continuidad del servicio, estableciendo plazos y procedimientos que aseguren la transición al igual que para el cierre del contrato.
Las cláusulas de término anticipado por parte de la entidad pública deben ser objetivas y fundarse en incumplimientos graves por parte del proveedor, que se encuentren bien definidos en las bases de licitación, con el fin de no incurrir en incertidumbre y tener claridad de las causales de término anticipado para ambas partes.
1.2.2.10. Cláusulas sobre Cierre del Contrato
El cierre del contrato corresponde a la finalización de la relación contractual entre las partes. Es un proceso normal en cualquier relación contractual, sin embargo, cuando la relación ha durado mucho tiempo, puede ocurrir que realizar este cierre no sea simple. Por esta razón se recomienda incorporar en las bases de licitación y en el posterior contrato, cláusulas que regulen este punto. Estas cláusulas deberían considerar, por ejemplo:
• Calendario de cierre: Establezca un evento o plazo prudencial a partir del cual se entiende que el contrato entra en etapa de cierre.
• Protocolo de fin de contrato: Se recomienda establecer en las bases de licitación la obligación de las partes de suscribir un protocolo de cierre de contrato, que contendrá el detalle de todas actividades a realizar y los responsables de cada una de ellas, para lograr un cierre de contrato ordenado. Este protocolo puede incluir según tipo de proyecto elementos como: entrega de códigos fuentes, licencias,
datos, documentación, soporte técnico, parametrización de sistemas, transferencia de know how, destrucción de información de propiedad del contratante, entre otros.
• Pagos finales: Dentro del esquema de pagos del servicio, una parte debería estar asociada al cumplimento a cabalidad por parte del proveedor del cierre del contrato. Uno de estos hitos puede ser la firma de un documento donde las partes declaren que el contrato se ha cerrado sin inconvenientes.
• Transición de un contrato a otro: Para cierto tipo de servicios, específicamente cuando el contratante externaliza procesos operacionales o de negocio a un privado, el cierre del contrato puede estar asociado al traspaso de las operaciones de un proveedor a otro. Por ejemplo, el organismo público puede haber externalizado durante 4 años su call center a una empresa específica. Durante la vida de este contrato el organismo público deberá volver a licitar puesto, que sabe el contrato dura sólo 4 años. El resultado de esta nueva licitación puede ser que el adjudicatario sea distinto al primer operador. En este caso, la transición del primer operador al segundo es compleja. Esto ocurre porque luego de 4 años el conocimiento que tendrá el primer call center del negocio del organismo público será muy superior al del segundo. Por este motivo se recomienda incorporar cláusulas en las bases de licitación y en el contrato, de manera que exista una transición colaborativa entre las partes. En el ejemplo del call center, se deberá entrenar a los agentes del nuevo operador, traspasar procedimientos, traspasar scripts, apoyar en las nuevas configuraciones de los sistemas de soporte, etc.
1.3. Cierre del Proceso de Licitación
Una vez publicado el proceso licitatorio en ChileCompra y luego de cumplido todas sus etapas según regulen las bases administrativas, corresponde la apertura de las ofertas, su evaluación y finalmente la adjudicación.
En este momento del proceso, el organismo público contratante deberá poner especial cuidado, de manera de traspasar a las empresas participantes los resultados de la evaluación de la manera más transparente y precisa posible, sin liberar información que pueda ser de carácter privado de las propias empresas. El objetivo es que los oferentes entiendan bien el resultado del proceso.
Para lograr este objetivo pueden existir distintos mecanismos, considere al menos las siguientes posibilidades:
• Publicación de informe ejecutivo de comisión de evaluación: Deberá existir un informe resumido que contenga los elementos medulares del resultado de la evaluación. Este documento deberá quedar disponible en el sistema ChileCompra. El informe debe mostrar con claridad cuáles fueron los componentes o factores que generaron el resultado del proceso. En todo caso, se debe siempre cuidar la imagen
de las empresas no adjudicadas. En este informe no se deben incluir materias que puedan vulnerar derechos de propiedad intelectual.
• Comunicación de los resultados del proceso: Es conveniente considerar una instancia para que el servicio comunique y explique a las empresas participantes las razones fundamentales por las que no se adjudicaron el proceso. Esta etapa debe estar circunscrita a los elementos de evaluación señalados en las bases y se debe evitar entrar en discusiones. Aquí lo importante es producir aprendizaje en las empresas.
1.4. Gestión del Contrato.
Una vez adjudicada la licitación, se deberá instalar un equipo que permita asegurar el buen desarrollo del proyecto. Para proyectos complejos, se recomienda constituir un comité de administración, compuesto de ejecutivos de alto nivel, con facultades suficientes para poder realizar una adecuada administración del contrato. A este comité responderá un encargado de proyecto que será la contraparte técnica de la empresa proveedora. Esta figura es clave para el éxito del contrato. Por este motivo, se recomienda analizar cuidadosamente las habilidades y conocimientos necesarios para ejercer esta función. En el caso que no exista el perfil adecuado en el organismo, se deberá buscar apoyo externo.
Se deben establecer períodos para que la entidad pública pueda revisar las entregas de las soluciones por el proveedor, a fin de aceptarlas o rechazarlas.
Finalmente, y dependiendo del tipo de proyecto, se recomienda también el uso de la figura de inspectoría técnica (ITO), para que a través de la opinión de un tercero confiable, se pueda monitorear el avance del proyecto y proponer medidas de mitigación.