Observatorio de Permanencia

Universidad Andina · Cohorte 2025-1

Observatorio de Permanencia

Seguimos a los estudiantes que ingresaron en 2025-1 para saber cuántos siguen en 2025-2 y a quién llamar antes de que se vayan.

CohorteEstudiantes nuevos matriculados en 2025-1
1.200
AbsorciónCohorte sobre admitidos únicos
82,8 %
RetenciónCohorte que sigue en 2025-2
85,4 %

Grupo 3 · Nicolás Galeano Ramírez y Laura Sofía Jerez Parra · Inteligencia de Negocios, UCN 2026-b2

Reto 1 · ETL

Limpiamos cinco fuentes y las unimos en una cohorte

Partimos de cinco archivos: 1.480 admisiones, 2.282 matrículas, 1.132 pagos, 19.200 registros de Moodle y 276 de Bienestar. Quedaron 1.450 admitidos únicos y una cohorte de 1.200 estudiantes.

  1. ExtracciónLeemos los CSV directo del ZIP y forzamos UTF-8.
  2. TransformaciónLimpiamos documentos, fechas, programas, periodos y notas.
  3. IntegraciónCruzamos las fuentes por documento, código y nombre.
  4. CargaPublicamos el modelo estrella y los archivos del sitio.

Reglas de limpieza aplicadas

Cada regla registra cuántas filas tocó. El ETL escribe este registro en cada ejecución.

N.º Problema Regla Etapa Filas
Descargar cohorte limpia (CSV)

Una fila por estudiante. Sin nombre, documento ni correo: cada uno lleva un código.

Volver a ejecutar el ETL

python -I etl/run_etl.py --zip Datos_Universidad_Andina.zip --out site/data

Usa solo la biblioteca estándar de Python. Sobre el ZIP original da otra vez 1.200 estudiantes.

Reto 2 · Modelo dimensional

Definimos un esquema estrella con dos hechos

Una fila por estudiante de la cohorte 2025-1 por periodo académico (2025-1 y 2025-2).

Modelo estrella del observatorio Dos tablas de hechos al centro, fact_permanencia y fact_admision, rodeadas de dimensiones. dim_estudiante y dim_periodo se relacionan con fact_permanencia; dim_fecha con fact_admision; dim_programa y dim_estrato con ambos hechos; dim_facultad se relaciona con dim_programa. Todas las relaciones son de uno a muchos. 1N 1N 1 NN 1 NN 1N 1N fact_permanencia id_estudiante · id_programa id_estrato · id_periodo matriculado · creditos accesos_s1_8 · desercion alerta_actual · alerta_nueva valor_liquidado promedio_periodo nota_prom_s4_s8 fact_admision id_programa · id_estrato id_fecha admitido · ingreso_cohorte puntaje_saber11 dim_estudiante código y colegio dim_estrato estratos 1 a 6 dim_fecha fecha de admisión dim_periodo 2025-1 · 2025-2 dim_programa 6 programas dim_facultad 3 facultades Cursiva: medida no aditiva. Línea: relación uno a muchos (1 en la dimensión, N en el hecho).
Programa, facultad y estrato son dimensiones compartidas: filtran los dos hechos. Por eso la absorción responde a los mismos filtros que la deserción.

Hecho fact_permanencia

Medidas por estudiante y periodo: 2.400 filas. Las medidas aditivas se suman entre estudiantes; las no aditivas se promedian y no se suman.

MedidaQué mideTipo
matriculado1 si el estudiante se matriculó en el periodo.Aditiva
creditosCréditos inscritos en el periodo.Aditiva
accesos_s1_8Accesos a Moodle en las semanas 1 a 8.Aditiva
alerta_actual1 si la regla actual lo alerta.Aditiva
alerta_nueva1 si la regla nueva lo alerta.Aditiva
desercion1 si no se matriculó en 2025-2.Aditiva
valor_liquidadoValor liquidado en la matrícula, en pesos.Aditiva
promedio_periodoNota media del periodo, de 0 a 5.No aditiva
nota_prom_s4_s8Promedio de las notas parciales de las semanas 4 y 8.No aditiva

Las tasas (absorción, retención, deserción, precisión y cobertura) tampoco se suman. La capa semántica las calcula como una suma dividida por otra.

Hecho fact_admision

Una fila por admitido único: 1.450 filas. Comparte programa, estrato y fecha con el otro hecho.

MedidaQué mideTipo
admitidoSiempre 1. Cuenta los admitidos.Aditiva
ingreso_cohorte1 si el admitido entró a la cohorte 2025-1.Aditiva
puntaje_saber11Puntaje Saber 11 del admitido.No aditiva

Dimensiones

DimensiónAtributosFiltra
dim_estudianteCódigo, tipo de colegio, banda Saber 11 e indicadores de Bienestar sin datos personales.fact_permanencia
dim_programaPrograma y su facultad.Los dos hechos
dim_facultadIngeniería; Ciencias Económicas y Administrativas; Ciencias Sociales y Humanas.Los dos hechos, por dim_programa
dim_estratoEstrato socioeconómico, de 1 a 6.Los dos hechos
dim_periodo2025-1 y 2025-2.fact_permanencia
dim_fechaFecha de admisión.fact_admision

Reto 3 · Arquitectura

Proponemos una arquitectura en capas, de la fuente al consejero

Moodle entra por streaming. El resto llega por lotes. Todo pasa por un lake con tres zonas antes de llegar al tablero y a las alertas.

Arquitectura de datos del observatorio Seis fuentes: Moodle, SIS, ERP y Bienestar (internas) e ICFES Saber 11 y calendario académico o portal MEN (externas). Moodle entra por streaming con Kafka o Event Hubs cada 5 minutos; las demás por lotes con Airflow: SIS y Bienestar a diario a las 2:00 a. m., ERP semanal, ICFES anual y calendario semestral. Ambas rutas llegan a la zona raw del data lake. Entre raw y clean se anonimizan los datos de Bienestar. Luego siguen clean, curated, el lakehouse o DW, la capa semántica, el tablero y el canal de alertas. El tablero lo usan directivos, consejeros, docentes y Bienestar. Las alertas salen por correo y Teams a los consejeros a diario a las 7:00 a. m. FUENTES INTERNAS FUENTES EXTERNAS Moodle actividad en el aula SIS matrículas y notas ERP pagos Bienestar registros de atención ICFES Saber 11 puntajes de ingreso Calendario / MEN académico y portal MEN eventoscada 5 min diaria2:00 a. m. semanal diaria2:00 a. m. anual semestral Streaming Kafka o Event Hubs Ingesta por lotes Apache Airflow programa y vigila cada carga micro-lotescada 5 min lotes diariosy semanal (ERP) DATA LAKE raw datos tal como llegan clean limpios y anonimizados curated modelo estrella Anonimización de Bienestar diaria diaria diaria Lakehouse / DW Delta Lake o DuckDB tras cadacarga Capa semántica métricas con dbt actualización diaria diaria 7:00 a. m. Tablero Power BI · 7 indicadores y filtros Canal de alertas correo y Teams consulta a demanda correo y Teams7:00 a. m. USUARIOS POR ROL Directivos decisión y metas Docentes seguimiento en aula Bienestar atención a estudiantes Consejeros llaman a los alertados
Cada flecha lleva su frecuencia. El rombo marca el punto donde se anonimizan los datos de Bienestar, antes de que lleguen a la zona clean.

Tecnologías elegidas

TecnologíaCapaPor qué la elegimos
Apache Kafka o Azure Event HubsStreamingRecibe los eventos de Moodle cada 5 minutos y conserva su orden aunque el consumo se retrase.
ADLS o Amazon S3Data lakeAlmacenamiento barato para las zonas raw, clean y curated, con permisos por carpeta.
Delta Lake con Spark o DuckDBLakehouse / DWTablas con control de versiones sobre el lake. DuckDB basta para el tamaño de este caso.
dbtCapa semánticaVersiona en SQL la limpieza y las métricas. Cada indicador queda definido una sola vez.
Apache AirflowOrquestaciónPrograma la carga de las 2:00 a. m., la semanal del ERP y el envío de alertas de las 7:00 a. m.
Hash con sal (Python)AnonimizaciónReemplaza el nombre por un código irreversible antes de la zona clean. La observación no sale de raw.
Power BITableroLos directivos ya lo usan. Se conecta a la capa semántica con filtros por programa, facultad y estrato.
Webhook de Teams y correoAlertasLlega a los consejeros donde ya trabajan y entrega la lista de alertados cada día a las 7:00 a. m.

Reto 4 · Tablero

Siete indicadores de la cohorte, con filtros en vivo

Los filtros recalculan todo al instante. El punto y la etiqueta de cada indicador comparan su valor con la meta.

Regla de alerta

Cohorte completa: 1.200 estudiantes

AbsorciónCohorte sobre admitidos únicos.

82,8 %

Cumple desde 85 %

Atención

RetenciónCohorte que sigue matriculada en 2025-2.

85,4 %

Cumple desde 88 %

Atención

DeserciónCohorte sin matrícula en 2025-2.

14,6 %

Cumple hasta 12 %

Atención

PromedioNota media de 2025-1, de 0 a 5.

3,38

Cumple desde 3,5

Atención

AlertadosEstudiantes que marca la regla elegida.

371

Cumple hasta 120

Crítico

PrecisiónDe los alertados, los que desertaron.

32,6 %

Cumple desde 50 %

Crítico

CoberturaDe los que desertaron, los que alertamos.

69,1 %

Cumple desde 60 %

Cumple

Deserción por programa

Las barras siguen los filtros. El programa elegido queda resaltado.

Metas del semáforo

Definimos tres niveles por indicador. Los mismos umbrales colorean el tablero.

Indicador Cumple Atención Crítico
Absorción85 % o más80 % a 85 %menos de 80 %
Retención88 % o más85 % a 88 %menos de 85 %
Deserción12 % o menos12 % a 15 %más de 15 %
Promedio3,5 o más3,0 a 3,5menos de 3,0
Alertados120 o menos121 a 200más de 200
Precisión50 % o más35 % a 50 %menos de 35 %
Cobertura60 % o más40 % a 60 %menos de 40 %

Reto 5 · Nueva alerta

Cambiamos la regla para alertar a menos y acertar más

La regla actual alerta a demasiados estudiantes para los consejeros. Buscamos una que cumpla dos metas: 120 alertados o menos y una cobertura de al menos 35 %.

Alertar si suma 2 accesos o menos en las semanas 7 y 8, o si su nota promedio de las semanas 4 y 8 es menor a 2,8 y acumula menos de 20 accesos en las semanas 1 a 8.

Regla actual

Alerta si la nota promedio de las semanas 4 y 8 es menor a 3,0, o si no tuvo accesos en las semanas 7 y 8.

DesertóNo desertó
Alertó121250
No alertó54775

Las celdas sombreadas son aciertos.

Alertados
371
Precisión
32,6 %
Cobertura
69,1 %

Regla nueva

Combina el abandono reciente en Moodle con la nota baja y poca actividad durante las ocho semanas.

DesertóNo desertó
Alertó7536
No alertó100989

Las celdas sombreadas son aciertos.

Alertados
111
Precisión
67,6 %
Cobertura
42,9 %

Capacidad de los consejeros: 120 estudiantes

La línea vertical marca la capacidad. La regla nueva cabe; la actual la triplica.

Regla actual 371
Regla nueva 111

Reto 6 · Prospectiva

Tres tecnologías para el siguiente paso

Cada una responde a un problema del caso, mueve un indicador del tablero y trae un riesgo que ya sabemos cómo controlar.

Streaming con feature store en tiempo realKafka o Event Hubs, con variables de Moodle calculadas al vuelo

Problema del caso
La alerta usa los accesos de las semanas 7 y 8. Quien se desconecta antes se detecta tarde y queda sin cubrir.
Indicador que mejora
Cobertura. La regla nueva cubre 42,9 %; la meta verde es 60 %.
Riesgo
Eventos tardíos o duplicados distorsionan los accesos y generan alertas falsas.
Mitigación
Ventanas por hora del evento, deduplicación por identificador y un reproceso nocturno que corrige la zona curated.

Modelo de priorización con gradient boostingOrdena a los alertados según su probabilidad de desertar

Problema del caso
Los consejeros atienden 120 estudiantes. Una regla de umbrales no dice a quién llamar primero.
Indicador que mejora
Precisión de los 120 estudiantes que se llaman. La meta verde es 50 %.
Riesgo
El modelo aprende del pasado. Puede favorecer a unos programas o estratos y el consejero no sabe por qué lo alertó.
Mitigación
Medimos precisión y cobertura por programa y estrato antes de activarlo, mostramos las variables que más pesan y dejamos la regla de umbrales como respaldo.

Catálogo y gobierno de datos con enmascaramientoLinaje, permisos por rol y datos de Bienestar protegidos

Problema del caso
Bienestar trae nombre y programa, sin documento. El cruce depende de normalizar nombres y la observación es un dato sensible.
Indicador que mejora
Calidad del cruce de Bienestar, que alimenta precisión y cobertura, y cumplimiento de la protección de datos.
Riesgo
El enmascaramiento puede ocultar datos que el consejero necesita para actuar.
Mitigación
Acceso por rol. El consejero ve el código y la alerta; la identidad se revela con permiso registrado en el catálogo.