Contratación de software gubernamental: guía práctica para funcionarios
Contratación de software gubernamental: guía práctica para funcionarios Utiliza una RFP solo cuando debas evaluar factores distintos del precio. Para todo lo demás, una RFQ o un vehículo de calendario GSA te permite formalizar el contrato más rápidamente y con menor exposición a impugnaciones.
Contratación de software gubernamental: guía práctica para funcionarios
Utiliza una RFP solo cuando debas evaluar factores distintos del precio. Para todo lo demás, una RFQ o un vehículo de calendario GSA te permite formalizar el contrato más rápidamente y con menor exposición a impugnaciones. Se aplican tres salvaguardas a toda adquisición de software del sector público, independientemente de la vía: cumplimiento del FAR, una postura de seguridad documentada (alineación con FedRAMP, FISMA o NIST SP 800-53) y criterios de evaluación defendibles y establecidos previamente.
Tus próximos pasos inmediatos:
-
Realiza un estudio de mercado para confirmar si existen soluciones comerciales antes de redactar requisitos personalizados.
-
Realiza una comprobación de la línea base de seguridad según la categorización FISMA de tu agencia y los requisitos de autorización de FedRAMP.
-
Involucra pronto a tu funcionario de contratación o a un equipo de contratación asistida si los requisitos son complejos o los plazos son ajustados.
Índice
-
¿Qué tipo de procedimiento de licitación se adapta a tu contratación de software gubernamental?
-
¿Cómo es realmente el ciclo de vida de la contratación de software?
-
¿Cómo se redactan los requisitos y se construye una matriz de puntuación defendible?
-
¿Qué requisitos de seguridad y cumplimiento se aplican al software gubernamental?
-
¿Cuándo deben utilizarse los servicios de contratación asistida?
-
Lista de verificación de diligencia debida de proveedores y señales de alerta
-
¿Cómo son los plazos realistas y el coste total de propiedad?
-
Cómo Ridiculous Engineering ayuda a los compradores gubernamentales
-
Ridiculous Engineering ayuda a los equipos de contratación que necesitan un socio técnico
¿Qué tipo de procedimiento de licitación se adapta a tu contratación de software gubernamental?
La elección entre RFI, RFQ y RFP es la primera decisión que determina todo lo que viene después. Si te equivocas, puedes sobredimensionar una compra sencilla o especificar insuficientemente una compleja.
| Vía | Más adecuada para | Cuándo utilizarla |
|---|---|---|
| RFI | Solo investigación de mercado | Antes de finalizar los requisitos; no produce adjudicación |
| RFQ | Alcance bien definido y centrado en el precio | COTS/SaaS con especificaciones conocidas, compras de importe reducido |
| RFP | Evaluación multifactorial | Importan el enfoque técnico, el historial de rendimiento o la prestación del servicio |
| GSA MAS / OneGov | Adquisiciones de TI prenegociadas | Adjudicación más rápida, condiciones de seguridad coherentes y precios por volumen |
| Cooperativa / adhesión | Rapidez, contrato existente | El alcance y los precios deben coincidir; se requiere la diligencia debida |
Los programas de compras de la GSA consolidan el gasto común en TI mediante instrumentos prenegociados y preparados para el cumplimiento normativo. Para muchas adquisiciones de software, un pedido conforme al Multiple Award Schedule (MAS) de la GSA es más rápido y conlleva menos riesgos que una licitación independiente.
Adherirse al contrato de otra agencia puede reducir semanas el plazo de adquisición, pero requiere confirmar que el alcance del contrato original cubre su caso de uso, que los precios siguen siendo competitivos y que las certificaciones de seguridad del proveedor siguen vigentes. Omitir esa comprobación es lo que hace que la adhesión salga mal.
Consejo profesional: Utilice solicitudes de propuestas (RFP) solo cuando deba evaluar factores distintos del precio. Utilizar por defecto una RFP para cada adquisición de software añade meses y aumenta el riesgo de impugnaciones sin mejorar los resultados.
¿Cómo es realmente el ciclo de vida de la adquisición de software?
Cada fase produce un artefacto específico. Omitir una suele significar tener que volver a abordarla más adelante con un coste mayor.
| Fase | Artefacto clave | Responsable principal |
|---|---|---|
| Requisitos e investigación de mercado | Informe de investigación de mercado, documento de requisitos | Responsable del programa/técnico |
| Licitación | Solicitud de cotización (RFQ), solicitud de propuestas (RFP) o solicitud de pedido | Responsable de contratación |
| Evaluación | Propuestas puntuadas, memorando de consenso | Panel de evaluación + responsable de contratación |
| Adjudicación | Contrato / pedido de trabajo | Responsable de contratación |
| Implementación | Plan de pruebas de aceptación, registros de despliegue | Responsable técnico + proveedor |
| Gestión del contrato | Informes de rendimiento, registro de modificaciones | Responsable de contratación + oficina del programa |
Los plazos varían considerablemente. Un pedido SaaS sencillo al amparo de un calendario de la GSA puede cerrarse en unas pocas semanas. Una RFP competitiva para una plataforma personalizada suele tardar varios meses desde la definición de los requisitos hasta la adjudicación, y la implementación añade meses adicionales según el alcance. La mayoría de los retrasos se producen durante la definición de requisitos y la evaluación, no durante la licitación.
El error más costoso en la adquisición de software del sector público es iniciar la licitación antes de que los requisitos estén consolidados. Las agencias que invierten de dos a cuatro semanas en una investigación de mercado estructurada acortan sistemáticamente su ciclo general de adquisición.
¿Cómo se redactan los requisitos y se crea una matriz de puntuación defendible?
Los requisitos centrados en los resultados describen lo que el sistema debe lograr, no cómo debe construirse. «El sistema deberá procesar 10.000 solicitudes de permisos al mes con un tiempo de actividad del 99,5 %» es comprobable. «El sistema deberá ser moderno y fácil de usar» no lo es.
Separe los criterios obligatorios de aprobado/suspenso de los elementos puntuables. Los criterios obligatorios eliminan las ofertas que no cumplen antes de que comience la puntuación. Los elementos puntuables diferencian entre las ofertas que cumplen.
| Factor de evaluación | Peso | Notas de puntuación |
|---|---|---|
| Enfoque técnico | — | Metodología, arquitectura, plan de integración |
| Rendimiento anterior | — | Referencias, alcance similar, actualidad |
| Postura de seguridad | — | Estado de FedRAMP, controles del NIST, respuesta ante incidentes |
| Precio / coste total | — | Licencias, implementación, mantenimiento continuo |
Una tabla de cumplimiento aplicada de forma coherente a todos los licitadores reduce la exposición a impugnaciones y facilita documentar la decisión de adjudicación.
Prácticas clave para evaluaciones listas para auditoría:
-
Fije los criterios de evaluación y las ponderaciones en la solicitud antes de recibir las propuestas.
-
Utilice un proceso de puntuación basado en el consenso, con las puntuaciones individuales documentadas antes del debate del panel.
-
Mantenga el control de versiones de todas las modificaciones de la solicitud y hojas de evaluación.
Consejo profesional: Documente cada decisión de puntuación con una frase justificativa. «El licitador A obtuvo 4/5 en el enfoque técnico porque…» es la frase que permite defenderse de una impugnación.
SaaS/COTS frente a desarrollo personalizado: ¿cómo elegir?
La respuesta sincera es que la mayoría de los organismos se decantan por COTS cuando sería apropiado un desarrollo personalizado y, ocasionalmente, encargan desarrollos personalizados cuando un producto comercial habría funcionado perfectamente. Las diferencias entre el software de código abierto y el propietario siguen un patrón similar.
| Dimensión | SaaS / COTS | Desarrollo personalizado |
|---|---|---|
| Más adecuado para | Flujos de trabajo habituales, casos de uso probados | Procesos únicos, integración con sistemas heredados, necesidades específicas de la misión |
| Coste total de propiedad | Menor coste inicial; los costes de suscripción se acumulan | Mayor coste inicial; menor a largo plazo si se mantiene adecuadamente |
| Tiempo de implementación | De semanas a meses | De meses a años (el enfoque modular lo acorta) |
| Riesgo de dependencia del proveedor | Alto; la portabilidad de los datos debe negociarse | Bajo si posee la propiedad intelectual y el código fuente |
| Nivel de seguridad | Autorización FedRAMP disponible para las principales plataformas | Debe incorporarse desde el principio; requiere alineación con NIST SP 800-53 |
| Modelo de mantenimiento | Actualizaciones gestionadas por el proveedor | Gestionado por la agencia o el contratista |
| Flexibilidad de las licencias | EULA estándar; derechos de modificación limitados | Derechos completos negociables mediante contrato |
FAR, parte 39 recomienda la contratación modular para grandes proyectos de TI, dividiendo el trabajo en incrementos más pequeños para reducir los riesgos técnicos y de calendario. Esta orientación se aplica por igual a los desarrollos personalizados y a las implementaciones de COTS por fases.
Consejo práctico: Al aceptar una licencia comercial, revise el EULA para comprobar las cláusulas de indemnización antes de firmar. La FAR, parte 12, desaconseja aceptar condiciones que creen obligaciones incompatibles con la legislación federal, incluida la Anti-Deficiency Act.
¿Qué requisitos de seguridad y cumplimiento se aplican al software gubernamental?
La seguridad no es una cuestión posterior a la adjudicación. Debe incluirse en la solicitud de ofertas, los criterios de evaluación y el contrato.
Expectativas mínimas según el tipo de sistema:
-
SaaS en la nube: autorización FedRAMP en el nivel de impacto que corresponda a sus datos (bajo, moderado o alto). Verifique el estado actual de la autorización en el FedRAMP Marketplace antes de la adjudicación.
-
Local o híbrido: documentación de cumplimiento de FISMA y una Authority to Operate (ATO) vigente, o un plan para obtenerla.
-
Todo el software: Correspondencia con las familias de controles pertinentes de NIST SP 800-53, especialmente control de acceso (AC), respuesta a incidentes (IR) y gestión de la configuración (CM).
Cláusulas contractuales que deben exigirse:
-
Derechos y propiedad de los datos (el Gobierno conserva en todo momento los derechos sobre sus datos).
-
Plazos de aplicación de parches y respuesta ante vulnerabilidades (los parches críticos en un plazo de 30 días son un estándar habitual).
-
Requisitos de notificación de incidentes (la notificación en un plazo de 72 horas es un umbral habitual).
-
Redacción sobre la limitación de responsabilidad revisada conforme a la legislación federal.
El nivel de seguridad es un factor de evaluación, no una casilla que marcar. Un proveedor con una autorización FedRAMP Moderate y un plan documentado de respuesta ante incidentes presenta un riesgo sustancialmente menor que uno con una autoafirmación y una política de seguridad vaga.
Los EULA comerciales suelen contener condiciones de indemnización o garantía que entran en conflicto con las normas federales de contratación. La FAR, parte 12, indica a los responsables de contratación que adquieran software comercial bajo licencias públicas estándar cuando estas sean compatibles con la legislación, y que señalen las condiciones que no lo sean. La revisión jurídica antes de la formalización no es opcional en contratos de alto valor o que impliquen datos sensibles. Para los requisitos de seguridad de confianza cero y de los contratistas federales, el nivel exigido ha aumentado considerablemente en los últimos años.
¿Cuándo debe utilizar servicios de adquisición asistida?
La adquisición asistida consiste en contratar a una organización de contratación externa, como un Center of Excellence de la GSA u otra unidad de contratación de una agencia, para que gestione la adquisición en su nombre. Su agencia conserva la responsabilidad técnica y la autoridad sobre los requisitos; el equipo de adquisición asistida se encarga de la solicitud de ofertas, el apoyo a la evaluación y la administración de la adjudicación.
Los servicios de adquisición asistida de la GSA reducen la carga administrativa y aportan vehículos de contratación previamente negociados y conocimientos especializados en materia de cumplimiento para adquisiciones complejas. Son especialmente útiles cuando su agencia carece de capacidad de contratación, cuando el requisito implica conocimientos especializados de TI o cuando un plazo ajustado hace poco práctica una solicitud de ofertas completamente interna.
La adquisición asistida no es un atajo para eludir la supervisión. Es una forma de reorientar la energía de su equipo hacia lo que solo su agencia puede hacer: definir los requisitos, establecer los criterios de aceptación y gestionar el rendimiento del proveedor después de la adjudicación.
Consejo práctico: Mantenga un responsable técnico de su oficina del programa durante toda adquisición asistida. El equipo de contratación gestiona el proceso; su equipo es responsable del resultado.
Lista de comprobación y señales de alerta para la diligencia debida del proveedor
La diligencia debida se realiza antes de la adjudicación, no después de que surja un problema.
Lista de comprobación:
-
Verifique las referencias de rendimiento anteriores para contratos de alcance y complejidad similares.
-
Confirme que el estado de autorización de FedRAMP o la documentación de FISMA estén actualizados.
-
Revise los informes SOC 2 de tipo II de los proveedores de SaaS que gestionen datos confidenciales.
-
Compruebe los indicadores de estabilidad financiera (años en el negocio, historial de contratos gubernamentales).
-
Confirme que los SLA de aplicación de parches y respuesta ante incidentes estén documentados y sean exigibles.
| Duración del contrato | Estándar mínimo |
|---|---|
| Disponibilidad del SLA | 99,5 % o superior para sistemas críticos para la misión |
| Respuesta a parches críticos | 30 días desde la divulgación |
| Devolución de datos al finalizar el contrato | 30 días, formato legible por máquina |
| Notificación de incidentes | 72 horas desde su detección |
| Criterios de aceptación | Definidos, medibles y vinculados a hitos de pago |
Señales de alerta: términos de EULA opacos o no negociables, cláusulas de indemnización que trasladan una responsabilidad ilimitada al Gobierno, una hoja de ruta del producto que no se ha actualizado en más de un año y compromisos de SLA sin compensación económica en caso de incumplimiento. Aprovecharse de un contrato existente puede ser rápido, pero estas comprobaciones siguen siendo aplicables.
¿Cómo son los plazos realistas y el coste total de propiedad?
| Tipo de contratación | Plazo de contratación | Implementación | Estabilización |
|---|---|---|---|
| SaaS mediante el calendario de GSA | Varias semanas | Unos meses | De varias semanas a unos meses |
| Solicitud de propuestas competitiva, COTS | Varios meses | Varios meses | Varios meses |
| Desarrollo personalizado (modular) | Varios meses | De varios meses a más de un año | Varios meses |
Factores de costes ocultos que los presupuestos suelen pasar por alto: migración de datos, integración con sistemas heredados, corrección de deficiencias de seguridad antes de la ATO, formación de usuarios finales y mantenimiento continuo después del periodo contractual inicial. Un análisis del coste total de propiedad a tres años, que incluya el incremento de las licencias y los costes de soporte, casi siempre produce una clasificación diferente de la que se obtiene al comparar los precios del primer año.
Consejo profesional: Estructure los contratos de desarrollo personalizado como incrementos modulares conforme a la Parte 39 del FAR. Cada incremento tiene sus propios criterios de aceptación y autorización de financiación, lo que limita la exposición si los requisitos cambian a mitad del proyecto.
Cómo Ridiculous Engineering apoya a los compradores gubernamentales
Ridiculous Engineering trabaja con organizaciones gubernamentales y del sector público en las etapas de definición de requisitos, entrega y soporte a largo plazo de una contratación.
Servicios que se ajustan directamente a las necesidades de contratación:
-
Definición de requisitos y redacción de especificaciones técnicas.
-
Diseño de arquitectura modular alineado con las estructuras contractuales de la Parte 39 del FAR.
-
Desarrollo seguro de software personalizado con alineación con los controles de NIST SP 800-53.
-
Integración de sistemas heredados y desarrollo de API.
-
DevOps, configuración de canalizaciones de CI/CD y arquitectura en la nube.
-
Implementación posterior a la adjudicación, pruebas y soporte de mantenimiento a largo plazo.
Los equipos de contratación pueden contar con Ridiculous Engineering mediante un enunciado de trabajo dentro de un vehículo existente, como subcontratista después de la adjudicación o mediante cooperación de adquisición asistida conforme a las normas de la agencia. El objetivo siempre es el mismo: ayudarle a definir lo que realmente necesita, desarrollarlo correctamente y mantenerlo en funcionamiento.
Conclusiones clave
Una contratación eficaz de software gubernamental requiere el tipo de solicitud adecuado, una postura de seguridad documentada y criterios de evaluación defendibles establecidos antes de recibir las propuestas.
| Aspecto | Detalles |
|---|---|
| Adapte la solicitud a la complejidad | Utilice una RFQ para compras centradas en el precio; reserve la RFP para evaluaciones multifactoriales, con el fin de ahorrar tiempo y reducir el riesgo de impugnaciones. |
| La seguridad es un factor de evaluación | Exija autorización de FedRAMP, alineación con NIST SP 800-53 y acuerdos de nivel de servicio exigibles para la aplicación de parches en todos los contratos de software. |
| Puntúe antes de recibir las propuestas | Fije los criterios y las ponderaciones de evaluación en la solicitud; documente la justificación de cada puntuación para estar preparado para las auditorías. |
| Utilice la contratación modular para grandes desarrollos | La Parte 39 del FAR recomienda dividir los grandes trabajos de TI en incrementos para limitar el riesgo de retrasos y conservar la flexibilidad de financiación. |
| Ridiculous Engineering como socio técnico | Ridiculous Engineering apoya a los compradores gubernamentales desde la definición de requisitos hasta la implementación posterior a la adjudicación y el mantenimiento a largo plazo. |
Ridiculous Engineering apoya a los equipos de contratación que necesitan un socio técnico
Los responsables de contratación gubernamental suelen saber exactamente qué resultado necesitan y cuentan con abundante orientación sobre los procesos. Lo que a menudo les falta es un socio técnico capaz de traducir los requisitos de la misión en un sistema desarrollable, seguro y mantenible, y que comprenda cómo funciona realmente la contratación pública.
Ridiculous Engineering ofrece desarrollo de software personalizado adaptado a los vehículos de contratación, desde colaboraciones basadas en enunciados de trabajo hasta contratos de entrega posteriores a la adjudicación. El equipo cubre la definición de requisitos, la arquitectura segura, la integración con los sistemas existentes de la agencia y el soporte a largo plazo, sin los gastos generales de un gran integrador de sistemas ni el riesgo de un proveedor que desaparezca después de la puesta en producción.
Para hablar sobre cómo Ridiculous Engineering puede apoyar su próxima adquisición de software, póngase directamente en contacto a través de la página de servicios de desarrollo de software personalizado.
Fuentes autorizadas y lecturas adicionales
-
FAR Parte 12: Adquisición de productos comerciales y servicios comerciales — regula la gestión de licencias de software comercial y los requisitos de revisión de los EULA.
-
FAR Parte 39: Adquisición de tecnología de la información — abarca la política de contratación modular y los procedimientos de adquisición de TI.
-
FAR 15.203: Solicitudes de propuestas — define la estructura de las RFP y los requisitos mínimos de contenido para adquisiciones competitivas.
-
Programas de compras de la GSA — servicios de adquisición asistida y soluciones informáticas pre negociadas.
-
GSA OneGov — compras centralizadas de software para obtener precios y condiciones de seguridad coherentes.
-
Mercado de FedRAMP — fuente autorizada para verificar el estado de autorización de productos en la nube.
-
Subparte 227.72 de las DFARS — normas específicas de defensa sobre los derechos y la documentación del software informático.
-
RFQ frente a RFP en licitaciones gubernamentales — análisis práctico de cuándo se aplica cada tipo de solicitud.
Preguntas frecuentes
¿Cuándo debe utilizar una RFP en lugar de una RFQ?
Utilice una RFP cuando deban evaluarse factores distintos del precio, como el enfoque técnico, el desempeño anterior o la postura de seguridad. Para compras de software bien definidas en las que el precio sea el principal factor diferenciador, una RFQ es más rápida y conlleva un menor riesgo de impugnación.
¿Qué es FedRAMP y por qué es importante para la adquisición de software?
FedRAMP es el programa federal de autorización para servicios en la nube. Exigir la autorización de FedRAMP en el nivel de impacto adecuado (bajo, moderado o alto) significa que los controles de seguridad del proveedor han sido evaluados de forma independiente, lo que reduce la carga y la exposición al riesgo de su agencia en materia de ATO.
¿Qué establece la Parte 39 de las FAR sobre los grandes proyectos de TI?
La Parte 39 de las FAR recomienda la contratación modular para grandes adquisiciones de TI, dividiendo el trabajo en incrementos más pequeños con criterios de aceptación definidos. Esto limita el riesgo de retrasos y conserva la flexibilidad de financiación si cambian los requisitos.
¿Cómo reduce la adquisición asistida el riesgo de contratación?
La adquisición asistida transfiere la administración contractual a un equipo especializado, como un centro de la GSA, mientras su agencia conserva la responsabilidad técnica y la autoridad sobre los requisitos. Es especialmente útil para compras complejas de TI, plazos ajustados o cuando la capacidad interna de contratación es limitada.
¿Puede Ridiculous Engineering apoyar una adquisición gubernamental de software?
Sí. Ridiculous Engineering trabaja con compradores gubernamentales en la definición de requisitos, el desarrollo personalizado seguro, la integración de sistemas y el soporte posterior a la adjudicación, estructurados para adaptarse a los mecanismos de contratación estándar, incluidos los acuerdos de declaración de trabajo y subcontratación.