Análisis de sistemas

Cómo construiría un sistema de calificación de licitaciones públicas

Una disección diseñada de la capa de coordinación bajo la contratación pública: descubrimiento de licitaciones, calificación frente a la capacidad real, extracción de requisitos, montaje de la oferta y seguimiento de plazos. Un modelo de laboratorio, no un proyecto para cliente.

Diagrama de una cadena de calificación de licitaciones públicas — descubrimiento, ajuste de capacidad, extracción de requisitos, montaje de la oferta, seguimiento de plazos — con la precisión de calificación marcada como el cuello de botella
En esta página

Respuesta directa

Un sistema de calificación de licitaciones públicas es una cartera de contratos que la empresa realmente podría ganar, construida monitoreando portales de contratación, puntuando cada anuncio frente a lo que la empresa hace de verdad y extrayendo lo que exige cada uno. Dile qué vendes y obtén cuatro contratos que vale la pena licitar, junto con los requisitos detrás de cada uno. Este es un sistema diseñado, no un proyecto desplegado. Viene del laboratorio Shopify Your Industry y nunca se ha vendido ni validado con un cliente.

Puntos clave

  • El producto no es un buscador. Es una preselección que alguien realmente va a leer.
  • El producto es la capa de coordinación: descubrimiento, calificación, extracción de requisitos, montaje de la oferta, plazos.
  • El cuello de botella es la precisión de la calificación. Dos preselecciones malas y el cliente deja de abrir el correo.
  • La cobertura de portales es desigual. Que haya datos estructurados a nivel de la UE no significa que los haya en cada portal nacional.
  • Esto es un modelo, como el sistema de reservas de flete. El sistema que realmente he construido es el bucle de seguimiento comercial en el CRM.

¿Qué problema es realmente responsabilidad de este sistema?

Las licitaciones están repartidas entre portales en formatos inconsistentes. Encontrar las tres que valen la pena cuesta más atención que escribir las ofertas, así que la mayoría de las empresas no encuentra ninguna.

Hoy el camino suele ser así:

  1. Alguien revisa un portal un viernes, cuando hay tiempo.
  2. Los términos de búsqueda coinciden con los contratos equivocados, o pasan por alto los correctos bajo otro código.
  3. Un anuncio prometedor resulta tener cien páginas, de las cuales solo cuatro importan.
  4. Para cuando se entienden los requisitos, ya pasó el plazo de aclaraciones.
  5. Los mismos datos de la empresa, certificados y referencias se vuelven a escribir por cuarta vez este año.
  6. Un contrato que la empresa podría haber ganado se cierra sin que nadie lo viera.

Nada de eso es redactar ofertas. Es información que se mueve entre un comprador, un portal, un responsable de oferta y quien tiene los certificados, cada uno con una pieza del rompecabezas. Esa es la capa de coordinación, y es el producto.

El flujo de trabajo existente que mapearía primero

Antes de cualquier llamada a un modelo, me sentaría con la persona que redacta las ofertas y repasaría las dos últimas: una ganada, una abandonada.

PasoQué pasa hoyQué suele fallar
DescubrimientoRevisiones manuales de portalesAnuncios relevantes que nunca se ven
Primer filtroTítulo y nombre del compradorCódigo de clasificación equivocado, alcance equivocado
LecturaUn paquete de PDF de cien páginasDías perdidos para descubrir que nunca encajaba
ElegibilidadSe revisa tardeFacturación, referencias o certificados descalifican al final
MontajeCopiar y pegar de la última ofertaCifras desactualizadas y certificados vencidos
PlazosUna entrada de calendario, si alguien la hizoSe pierden las ventanas de aclaración, presentaciones apresuradas

Si esa tabla está mal, el sistema está mal. Prefiero pasar una semana en la tabla que un mes en la construcción equivocada.

Diagrama de la cadena de licitaciones públicas: descubrimiento, precisión de calificación como cuello de botella, extracción de requisitos, montaje de la oferta y un responsable de oferta humano.

Cómo funcionaría el sistema

Descubrimiento de licitaciones

El sistema monitorea las fuentes de forma continua, no un viernes. TED, el suplemento de anuncios de la UE, publica datos estructurados y ofrece una API, así que la cobertura ahí es confiable. Muchos portales nacionales y regionales no, y ahí la cobertura significa scraping, alertas por correo o una persona. Yo mostraría la cobertura de fuentes en la interfaz en lugar de dar a entender que el proceso está completo. Por encima de los umbrales de la UE la publicación está armonizada; por debajo, se aplican normas nacionales y portales locales, y ese límite es donde vive la mayoría de los contratos perdidos.

Calificación frente a la capacidad

Cada anuncio se puntúa frente a un perfil de capacidad: qué entrega realmente la empresa, dónde puede entregar, a quién puede asignar y qué puede demostrar. Los códigos de clasificación son una señal de partida, no la respuesta, porque los compradores codifican el mismo trabajo de forma distinta. El resultado es un juicio de ajuste con el razonamiento y los hechos descalificantes visibles, para que el responsable de la oferta pueda anularlo de un vistazo. Aquí la precisión importa más que la exhaustividad, y es una decisión de diseño deliberada: prefiero perder un contrato marginal que gastar la semana de un cliente en uno malo.

Extracción de requisitos

Del paquete documental, el sistema extrae lo que un licitador debe cumplir: elegibilidad, umbrales de facturación y referencias, certificados, personal, estructura de lotes, criterios de adjudicación y ponderaciones, formato de presentación y todas las fechas. Cada elemento extraído lleva un enlace a la cláusula de la que proviene. Un requisito sin referencia a la fuente es una suposición, y una suposición en una licitación sale cara.

Montaje de la oferta

Los componentes reutilizables —perfil de la empresa, referencias, certificados, memorias técnicas, anexos estándar— se guardan una vez y se versionan. El sistema prepara un borrador contra la estructura extraída y marca lo que es trabajo genuinamente nuevo frente a lo que se reutiliza. La ficha del laboratorio llama a esto una oferta que arranca en el setenta por ciento. Eso es un objetivo de diseño, no un resultado medido, y no lo repetiría como evidencia hasta que algo se haya construido y contado de verdad.

Seguimiento de plazos

Las ventanas de aclaración, los plazos de presentación, las visitas al sitio y los periodos de validez se convierten en elementos con fecha y escalamiento. Perder un plazo de aclaración es un fallo silencioso: la oferta igual se presenta, solo que más débil. El sistema los marca por separado de la fecha de presentación, porque son los que la gente pierde de vista.

¿Qué queda bajo control humano?

  • La decisión de licitar.
  • Cada declaración de elegibilidad y autodeclaración, que es una declaración legal de la empresa.
  • El precio.
  • El contenido final de la respuesta técnica.
  • La presentación en sí. Nada lo archiva una máquina.

El sistema prepara, una persona firma. Es la misma regla que sigo en el proyecto del CRM, y la nota de Anthropic sobre construir agentes efectivos plantea el mismo argumento: mantener el flujo simple e inspeccionable antes de añadir autonomía.

Cómo mediría el avance

Primero las líneas base, y solo líneas base, porque no se ha construido nada:

  • Anuncios revisados al mes, y horas dedicadas a revisarlos.
  • Contratos que la empresa descubrió después que había perdido.
  • Proporción de anuncios abiertos abandonados tras la lectura, y cuántas horas invertidas.
  • Ofertas presentadas por trimestre, y cuántas fueron descalificadas por elegibilidad en lugar de perdidas por mérito.
  • Días entre la publicación del anuncio y la decisión de licitar.

Aquí, autoaprendizaje significa señales de uso, correcciones del responsable de la oferta a la puntuación de ajuste y evaluación de las decisiones de calificación frente a lo que el cliente realmente persiguió, revisado por una persona. No significa que el sistema amplíe su propio filtro en silencio para parecer ocupado.

Cuándo esta es la construcción equivocada

  • La calificación no se puede hacer precisa. Este es el cuello de botella. Si el ajuste depende de relaciones, conocimiento local o un criterio que el cliente no puede articular, la preselección estará equivocada y se abandonará.
  • La empresa no quiere trabajo público. Los contratos públicos conllevan administración, condiciones de pago y exposición a auditorías que no toda empresa quiere. El descubrimiento no cambia eso.
  • La capacidad para licitar es la restricción real. Si la empresa solo puede escribir dos ofertas al trimestre y ya encuentra cuatro, una cartera más grande no es el problema.
  • Los portales relevantes están cerrados. Donde los anuncios llegan por correo postal, por lista de distribución de una asociación o por un portal sin interfaz utilizable, la cobertura la da una persona, y la economía cambia.
  • Nadie es dueño del proceso. Sin un responsable de oferta designado, una preselección calificada es otro informe sin leer.

Cómo se conecta esto con el proyecto

Este caso es uno de los modelos en Shopify Your Industry. El análisis de flete tiene la misma forma y una pared distinta: allí el lado de la oferta, aquí el falso positivo. El patrón de monitoreo y extracción es más cercano al de la Base de Datos de Oportunidades, que escanea de forma continua y deja que una persona decida. El único sistema de este sitio que realmente está en funcionamiento es el bucle de seguimiento comercial en el CRM.

Si esta capa de coordinación ya existe en tu empresa como una revisión de portal los viernes, el punto de partida operativo es la automatización de flujos de trabajo con IA. Si quieres que lo miremos con honestidad, describe el cuello de botella. Si solo quieres el próximo análisis, el boletín es suficiente.

Resumen

La abstracción cabe en una línea: dinos qué vendes, y aquí están los contratos que vale la pena licitar. El resultado es una preselección que vale la pena leer y una oferta que no empieza desde una página en blanco. Entre medias hay una capa de coordinación aburrida que mueve información entre un comprador, un portal y la persona que tiene que firmar la respuesta. Esto es un modelo. Seguirá siéndolo hasta que alguien que licita para vivir describa dónde falla realmente la calificación.

Preguntas frecuentes

¿Este sistema funciona hoy para algún licitador?+

No. Es un modelo del laboratorio Shopify Your Industry. No se ha construido, vendido ni validado con una empresa que licite en contratos públicos. Todo lo aquí descrito es la forma que yo construiría, y los puntos donde espero que falle.

¿Cuál es el cuello de botella real?+

La precisión de la calificación. Un falso positivo le cuesta al cliente una semana de lectura y me cuesta un cliente perdido. Una preselección equivocada dos veces es peor que ninguna preselección, porque el cliente deja de abrirla.

¿El sistema presenta la oferta?+

No. Nada se envía por una máquina. Un responsable de oferta designado revisa, completa y presenta. La presentación es un acto comercial vinculante con declaraciones de elegibilidad adjuntas.

¿Es 'una oferta que arranca en el 70 por ciento' un resultado medido?+

No. Es un objetivo de diseño de la ficha del laboratorio. No se ha construido nada, así que no hay una cifra medida de cuánto de una oferta cubren realmente los componentes reutilizables.

¿Puede monitorear todos los portales?+

No por igual. TED publica datos estructurados y ofrece una API. Muchos portales nacionales y regionales no lo hacen, así que la cobertura ahí depende del scraping o de revisiones manuales, y debería mostrarse como cobertura, no darse por supuesta.

Fuentes

  1. TED — Tenders Electronic Daily, suplemento del Diario Oficial de la UE: Oficina de Publicaciones de la Unión Europea
  2. Contratación pública — normas y política de la UE: Comisión Europea
  3. Building effective agents: Anthropic