Fuente de Datos

Origen, naturaleza y alcance de los datos que alimentan este dashboard.

Sobre los Datos

Los datos utilizados en esta aplicación provienen del SECOP II (Sistema Electrónico de Contratación Pública) y de las bases de datos de sanciones, publicados en la plataforma datos.gov.co (API Socrata). Los datos se presentan sin modificación, tal como se encuentran en la fuente original.

El sistema integra 12 datasets de datos abiertos que se descargan de forma automatizada mediante un orquestador externo (n8n) que dispara los procesos de carga con la API key.

Datasets Integrados

Dataset ID Tabla en el dashboard Fuente
SECOP II - Contratos Electrónicos jbjy-vk9h contratos — base de todo el análisis datos.gov.co
SECOP II - Adiciones cb9c-h8sn adiciones datos.gov.co
SECOP II - Ejecución Contratos mfmm-jqmq ejecuciones datos.gov.co
SECOP II - Suspensiones de Contratos u99c-7mfm suspensiones — suspensiones y reanudaciones por contrato datos.gov.co
SECOP II - Facturas ibyt-yi2f facturas — trazabilidad de pagos por contrato datos.gov.co
Proponentes por Proceso SECOP II hgi6-6wh3 proponentes — competencia por proceso datos.gov.co
SECOP II - Garantías gjp9-cutm garantias — pólizas por contrato datos.gov.co
SECOP II - Procesos de Contratación p6dx-8zbt procesos — puente contrato↔proponentes + datos de competencia (respuestas, adjudicación) datos.gov.co
Multas y Sanciones SECOP I 4n4q-k399 sancionados — primeras 2 filas; cargadas juntas vía /populed datos.gov.co
Antecedentes de SIRI iaeu-rcn6 sancionados — sanciones disciplinarias certificables; cargadas juntas vía /populed datos.gov.co
SECOP II - Multas y Sanciones it5q-hg94 sanciones_secopii — sanciones vigentes asociadas a procesos de SECOP II datos.gov.co
SECOP II - Plan de Pagos uymx-8p3j plan_pagos — pagos programados por contrato datos.gov.co

Análisis de Co-Ocurrencia de Proponentes

El dashboard detecta proponentes que se presentan juntos de manera recurrente en los mismos procesos de contratación — un indicador de afinidad competitiva: quién se presenta con quién y con qué frecuencia. El análisis cruza los datasets de proponentes y procesos (el puente que une contratos con sus requisiciones, formato CO1.BDOS.* → CO1.REQ.*).

Las asociaciones se computan en tres niveles (pares, tríos y cuartetos), mediante generalizaciones de la misma query: a JOIN b para pares, a JOIN b JOIN c para tríos, etc., con la condición a < b < c < d para evitar duplicar combinaciones. Sobre este grafo también se detectan clústeres maximales (Bron–Kerbosch) — grupos cerrados completos donde todos los integrantes co-ocurren entre sí.

  • Procesos juntos: número de procesos de contratación en los que todos los integrantes del grupo se presentaron en competencia.
  • Solapamiento min (%): qué porcentaje de la actividad del integrante con menos procesos se comparte con el resto del grupo. Alto = su actividad está mayormente compartida con el grupo.
  • Peso relativo por proveedor: en la página de cada proveedor, qué porcentaje de su actividad total (y de la del asociado) representa la co-ocurrencia.
  • Exclusividad: el complemento del solapamiento — porcentaje de procesos donde un integrante compite sin el otro. Exclusividad baja = "nunca se separan".
  • Lift (x): cuántas veces más probable es que el grupo se presente junto respecto a lo esperable al azar — destaca las asociaciones que serían poco probables al azar.
  • Clústeres maximales (Bron–Kerbosch): camarillas donde todos los miembros co-ocurren entre sí; el algoritmo encuentra el elenco completo, no fragmentos.

El ranking de pares se muestra en la página de inicio; los rankings por entidad y proveedor viven en cada perfil de entidad y perfil de proveedor (con el peso relativo de cada miembro). Los rankings de tríos, cuartetos y camarillas maximales están en la página dedicada de co-ocurrencia.

Alertas de Garantías Vigentes

El dashboard expone una métrica de auditoría civil: cuántos contratos en estado En ejecución no cuentan con ninguna garantía vigente (es decir, ninguna póliza con estado Aceptada cuya fecha de fin sea hoy o posterior), y cuánto valor monetario acumulado representa esa exposición sin cobertura. Esta señal apunta a un riesgo operativo y jurídico para la entidad contratante: si el contrato incumple, no hay respaldo de póliza que responda.

Definiciones operativas (ver spec):

  • Contrato vigente: contratos.estado_contrato = 'En ejecución'
  • Garantía vigente: garantias.estado = 'Aceptada' AND garantias.fecha_fin_poliza >= today (UTC)
  • Contrato sin garantía vigente: contrato vigente que NO tiene ninguna garantía vigente — query con subquery NOT EXISTS correlacionada.

La señal está disponible en cuatro puntos del sitio:

Out-of-scope (sigue como trabajo futuro): notificaciones automáticas (email/Slack) cuando un contrato queda sin cobertura; histórico de cobertura (snapshot diario); cruce con sanciones vigentes (proveedor sancionado + contrato sin garantía = alerta doble); soporte para otros estados de contrato vigentes (Activo, Suspendido).

Metodología

  • Recolección: descarga desde la API pública de datos.gov.co (Socrata) mediante workers de carga, disparados por un orquestador externo (n8n) con la API key del sistema.
  • Deduplicación: los datasets sin identificador oficial (suspensiones, facturas, garantías, proponentes) se deduplican con un hash determinístico — las corridas repetidas no duplican datos.
  • Puente de procesos: los proponentes se unen a los contratos a través de la tabla procesos (un portafolio CO1.BDOS.* puede contener varias requisiciones CO1.REQ.* — relación 1:N).
  • Indicadores: los contadores de cada contrato (suspensiones, reanudaciones, adiciones, proponentes, garantías, facturas) se calculan y sincronizan al final de cada carga.
  • Análisis: la co-ocurrencia de proponentes (pares, tríos, cuartetos, clústeres maximales + lift y exclusividad) y las alertas de garantías vigentes se computan en cada vista desde la DB local.
  • Trazabilidad: cada corrida de carga queda registrada con fecha de inicio y fin en la página de Estadísticas.

Limitaciones

  • Los datos se presentan tal como vienen de la fuente original — pueden existir errores, tildes o inconsistencias propios de los datos públicos.
  • En las sanciones y amonestaciones no siempre se tiene claro cuándo deja de estar vigente la amonestación o su duración.
  • Los datasets de gran volumen (facturas, proponentes, garantías, suspensiones) se cargan acotados a los contratos presentes en la base local.
  • La actualización de los datos depende del orquestador externo (n8n) y de la disponibilidad de la API de datos.gov.co.
  • Las alertas de garantías vigentes dependen de la calidad del campo fecha_fin_poliza en el dataset garantias: si la fecha falta o tiene datos sucios, el contrato puede aparecer falsamente como "sin cobertura".
  • El dataset de garantías en producción tiene cobertura parcial (~91.7k garantías cargadas contra ~1.7M contratos en ejecución) — los conteos de "sin garantía vigente" pueden inflarse por ausencia de datos, no necesariamente porque la garantía no exista.
← Volver al inicio