# Parte 4 — Diseño de dashboards (FASE 4) > Encargo: dashboards útiles, no bonitos. Cada ficha responde: **Nombre · Objetivo · Usuarios · KPIs · Gráficas · Filtros · Drill-down · Alertas · Acciones sugeridas**, más una línea de **factibilidad** que dice sin rodeos qué se puede construir hoy y qué necesita antes. > > 🟢 construible hoy · 🟡 construible con transformación o con advertencia de calidad · 🔴 requiere un habilitador previo (ver Parte 7) --- ## 4.0 Sistema de diseño: siete reglas transversales Antes de las fichas, las reglas que deben aplicarse a los 51 dashboards. Sin ellas se repetirán los errores auditados en la Parte 3. 1. **Barra de filtros única y persistente.** Los mismos seis filtros en todos los dashboards, guardados en sesión: **Periodo** (con presets `Hoy`, `Esta semana`, `Este mes`, `Semestre actual`, `Semestre anterior`, `Últimos 12 meses`, `Personalizado`), **Sede**, **Área/Facultad**, **Categoría de espacio**, **Canal de origen**, **Tipo de solicitante**. Cada filtro aplicado debe quedar visible como *chip* removible. Hoy los tres dashboards existentes construyen sus filtros por separado y el de activos no tiene ninguno. 2. **Comparativa obligatoria.** Todo KPI numérico muestra el valor, la variación contra el periodo equivalente anterior y una *sparkline* de 12 puntos. El helper `delta()` ya existe y funciona ([GraficasController.php:46](../../app/controllers/GraficasController.php#L46)); hay que generalizarlo. **Y para instituciones educativas el comparativo por defecto debe ser «mismo periodo del semestre anterior», no «mes anterior»**: comparar marzo con diciembre no informa nada (relación pico/valle real de 17:1). 3. **Honestidad del dato, como componente de UI.** Cada tarjeta y cada gráfica declara: - **Cobertura**: `% de filas con el dato necesario`. Si es <70 %, la cifra se muestra en gris con la leyenda «basado en N de M registros». - **Frescura**: «datos al {timestamp}» tomado de la última corrida del agregado. - **Rango efectivo de la fuente**, no el del filtro. Si el rango pedido tiene <30 % de cobertura en la tabla, **se muestra la cobertura en lugar del gráfico**. - **Supresión automática de dimensiones degeneradas**: si una dimensión tiene una sola clase (`Sede=1` en el 100 %), el gráfico no se pinta; se muestra un aviso. Esto evita el gráfico de una sola barra al 100 % que simula insight. - **Prohibido `COALESCE(campo, 0)` en métricas de tasa.** Todo denominador es explícito. 4. **Drill-down en tres saltos, siempre igual.** Agregado → segmento → **fila de hecho**. El último salto debe llegar a la reserva, la sesión o el equipo concreto, con enlace a su pantalla operativa. Un dashboard del que no se puede salir hacia la acción es un informe, no un tablero. Hoy ningún dashboard tiene drill-down. 5. **Cada alerta lleva dueño, umbral y acción.** Una alerta sin destinatario nominal es ruido. El sistema ya tiene los dos canales (`alertas` in-app con fan-out por rol, y `alertas_email` con worker) y **le falta el motor de reglas** y la deduplicación anti-fatiga: nada impide hoy enviar la misma alerta 288 veces al día si el cron corre cada 5 minutos. 6. **Ninguna cifra sin acción sugerida.** Cada dashboard cierra con un bloque «Qué hacer con esto», con 3–5 acciones enlazadas a la pantalla donde se ejecutan. 7. **Rendimiento por precálculo, no por optimización de consulta.** Los dashboards leen tablas de agregados refrescadas por cron, nunca el OLTP en caliente. Regla dura: **ningún dashboard puede descargar un histórico completo para filtrarlo en memoria** — es exactamente lo que hace hoy el dashboard de Guacamole y es lo que lo hará caer en la primera demo con volumen real. --- # BLOQUE A — Los 30 dashboards solicitados --- ## DB-01 · Dashboard Ejecutivo 🟡 **Objetivo.** Responder en una pantalla, sin scroll, las cinco preguntas de un comité directivo: ¿cuánto servicio prestamos?, ¿a quién?, ¿estamos usando lo que tenemos?, ¿cuánto se desperdicia?, ¿vamos mejor o peor que el semestre pasado? **Usuarios.** Rector, Vicerrector Administrativo, Director TIC, Secretaría General. **KPIs (8 tarjetas, con delta contra semestre anterior).** 1. **Personas-hora atendidas** — `SUM(CupoConsumido × minutos)/60`. Es la métrica de servicio, no de transacciones. Hoy nadie la usa aunque el dato existe. 2. **% de ocupación de la capacidad ofertada** 🔴 (habilitador 4). 3. **Horas desperdiciadas** = no-show + cancelación tardía + reservado-no-usado. **Traducido a coste**: horas × coste/hora del espacio. 4. **Tasa de no-show** 🟡 (requiere que el cron corra). 5. **Tasa de cancelación real** 🟡 (universo unificado `citas` ∪ `citas_canceladas`). 6. **Cobertura poblacional**: estudiantes distintos atendidos / matriculados 🔴 (requiere el total de matriculados como parámetro). 7. **% de servicio prestado en modalidad remota** 🔴 — el KPI que justifica el diferenciador. 8. **Índice de salud del dato** — % de reservas con cliente vinculado, con recurso identificado y con entrega registrada. **Un dashboard ejecutivo que no declara la calidad de su propio insumo es una trampa.** **Gráficas.** (a) Serie de personas-hora por semana con banda del semestre anterior superpuesta. (b) Barras horizontales de horas por categoría de espacio, con la porción desperdiciada en color de alerta. (c) Mapa de calor sede × mes. (d) Embudo institucional: solicitudes → aprobadas → usadas → cerradas correctamente, con las fugas cuantificadas y etiquetadas. (e) Termómetro de capacidad: ofertada / reservada / usada. **Filtros.** Periodo (default: semestre en curso), Sede. **Drill-down.** Cada tarjeta abre el dashboard temático correspondiente; el embudo abre la lista de reservas en la fuga seleccionada. **Alertas.** Ocupación global <35 % o >85 % dos semanas seguidas; horas desperdiciadas por encima del 15 % del total ofertado; caída >20 % en personas-hora contra el mismo periodo del semestre anterior. **Acciones sugeridas.** Convocar revisión de espacios subutilizados; ajustar política de no-show; aprobar o frenar inversión en equipos. **Factibilidad.** Con el universo unificado y el cron: 5 de 8 KPIs hoy. Los 3 restantes dependen de los habilitadores 1, 4 y 5. **Este dashboard debe reemplazar el actual «Hub de dashboards»**, que hoy no comunica ningún número. --- ## DB-02 · Utilización de laboratorios 🟡 **Objetivo.** Decidir cuántas horas de laboratorio abrir, en qué franjas y con cuántos monitores. **Usuarios.** Coordinador de Laboratorios, Director TIC, Decano de Ingeniería/Ciencias. **KPIs.** Horas ofertadas · horas reservadas · **horas realmente usadas** · % de ocupación · sesiones · usuarios únicos · duración media y p95 · % de puestos ocupados en la hora pico · horas perdidas por bloqueo · tasa de no-show del laboratorio. **Gráficas.** (a) Heatmap hora × día de **% de ocupación** (no de conteo — la diferencia entre un auditorio y un cubículo con 2 reservas cada uno). (b) Barras apiladas por laboratorio: reservado / usado / desperdiciado. (c) Curva de utilización de puestos a lo largo del día con la línea de capacidad instalada. (d) Serie semanal con marcas de receso y parciales. (e) Tabla de laboratorios ordenada por % de ocupación con semáforo. **Filtros.** Periodo, Sede, Laboratorio, Categoría, Canal (**crítico: la práctica libre y la reserva de clase tienen curvas radicalmente distintas** — plana vs. picos a las 7 y 9 — y mezclarlas destruye la información). **Drill-down.** Laboratorio → PC individual → sesiones del PC → reserva concreta → cliente. **Alertas.** Laboratorio con ocupación <25 % durante 3 semanas → candidato a reducir horario. Laboratorio >90 % en una franja → candidato a ampliar o replicar. Laboratorio con 0 sesiones en 14 días → revisar publicación en el portal. **Acciones sugeridas.** Cerrar franjas muertas; abrir franjas saturadas; reasignar monitores; mover equipos entre laboratorios. **Factibilidad.** Todo el numerador es 🟢. El % de ocupación es 🔴 hasta el habilitador 4. **Y hay que corregir la definición**: hoy «laboratorio» = `agendas.PortalPracticaLibre=1`, una bandera de configuración usada como dimensión. --- ## DB-03 · Utilización de aulas 🟡 **Objetivo.** Saber si la malla de horarios está aprovechando el aula o si se están reservando espacios que quedan vacíos. **Usuarios.** Director de Infraestructura, Director Académico, Registro Académico. **KPIs.** % de ocupación por aula · **% de aforo aprovechado** (`SUM(CupoConsumido)/CapacidadPersonas`) · horas reservadas vs. usadas · tasa de no-show · reservas por aula · aulas sin uso · **índice de sobredimensión** (aulas grandes usadas por grupos pequeños). **Gráficas.** (a) Matriz aula × franja con doble codificación: color = ocupación temporal, tamaño del punto = aforo aprovechado. **Es la gráfica que revela el desperdicio más caro: un auditorio de 200 puestos reservado para 8 personas.** (b) Dispersión capacidad vs. aforo usado, con la diagonal ideal. (c) Ranking de aulas por horas ociosas absolutas (no por porcentaje: 20 % de un auditorio de 200 duele más que 20 % de un cubículo). **Filtros.** Periodo, Sede, Edificio 🔴, Rango de aforo, Categoría. **Drill-down.** Aula → franja → reserva → solicitante y su programa. **Alertas.** Aula con aforo aprovechado <30 % de forma recurrente; aula con ocupación >85 %; aula reservada y con 0 asistentes registrados. **Acciones sugeridas.** Reasignar grupos pequeños a aulas pequeñas; liberar aulas grandes para eventos; renegociar la malla con Registro Académico. **Factibilidad.** 🔴 en la parte que más importa: **`citas` no guarda asistentes reales** (`CupoConsumido` es siempre 1 y mide lo reservado, no lo asistido). La generación anterior tenía `citas.Asistentes` — 100 % vacío, lo que sugiere que el problema no es sólo de esquema sino de proceso operativo. **Sin captura de asistentes, el % de aforo aprovechado es inalcanzable.** --- ## DB-04 · Utilización de equipos 🔴 **Objetivo.** Decidir compra, baja y redistribución del parque de equipos con evidencia de uso. **Usuarios.** Director TIC, Coordinador de Laboratorios, Director Financiero. **KPIs.** Horas de uso por equipo · sesiones por equipo · **índice de Gini de la distribución de uso** (el hallazgo de producción: 10 equipos de 764 con el 80 % del uso) · días sin uso · % de disponibilidad técnica · equipos en mantenimiento · valor del parque ocioso · **coste por hora de uso**. **Gráficas.** (a) **Curva de Lorenz del uso del parque** — una sola imagen que comunica «el 1 % de tus equipos hace el 80 % del trabajo». (b) Barras horizontales de horas por equipo con umbrales de sobreuso y de ociosidad. (c) Serie de disponibilidad diaria por laboratorio. (d) Tabla accionable: equipo · ubicación · horas · días sin uso · estado · recomendación. **Filtros.** Periodo, Sede, Laboratorio, Tipo de equipo, Estado. **Drill-down.** Equipo → historial de sesiones (presenciales y remotas) → reserva → cliente. **Alertas.** Equipo con >150 % del uso medio → riesgo de fallo por sobreuso, programar preventivo. Equipo con 0 uso en 30 días → verificar publicación, permisos o avería silenciosa. Equipo con >20 % de intentos de conexión fallidos → cola de mantenimiento. **Acciones sugeridas.** Rotar equipos entre laboratorios; adelantar mantenimiento preventivo del top de uso; dar de baja o reubicar los ociosos; **balancear la asignación automática** (hoy `PrestamoInmediatoAutoAsignar` se lee y nunca se usa en ninguna decisión). **Factibilidad.** 🔴 y es el caso más claro de la auditoría. Requiere: **unificar los dos inventarios** (habilitador 5), `datetime` en entrega y devolución, y columnas de entrega/condición en `citas_activos`. Hoy `activos` tiene 0 filas y el «uso» que se puede calcular es **tiempo agendado, no tiempo usado**. --- ## DB-05 · Escritorio remoto (visión general) 🔴 **Objetivo.** Demostrar y gobernar el diferenciador comercial: cuánto servicio se presta sin que el estudiante venga al campus. **Usuarios.** Director TIC, Rector (para la narrativa institucional), Coordinador de Laboratorios. **KPIs.** Sesiones remotas · horas remotas · usuarios únicos · **concurrencia máxima** · duración media/p50/p95 · % de sesiones fuera del campus · **tasa de aprovechamiento de la reserva remota** (reservó ¿y se conectó?) · tasa de fallo de conexión · sesiones huérfanas (indicador de salud del dato). **Gráficas.** (a) Serie diaria de sesiones y horas con eje de fechas denso (sin él los días sin uso desaparecen y la tendencia miente). (b) **Curva de concurrencia por franja de 15 min con la línea de capacidad** — la métrica más pedida y la que más se calcula mal. (c) Heatmap hora × día. (d) Distribución de duración en 6 buckets, con el bucket «<5 min» destacado como termómetro de calidad. (e) Embudo: reserva remota → intento → sesión establecida → sesión con uso efectivo (>5 min). **Filtros.** Periodo, Laboratorio, Equipo, Protocolo, Origen (campus / fuera). **Drill-down.** Día → sesión → equipo → reserva → cliente. **Alertas.** Concurrencia >85 % de la capacidad; tasa de fallo >10 %; sesión activa 2× por encima del p95 (posible sesión abandonada); sesión huérfana con más de 6 h. **Acciones sugeridas.** Ampliar equipos con acceso remoto; cortar sesiones abandonadas; escalar el laboratorio con más demanda remota. **Factibilidad.** 🔴. Tres bloqueos: **0 filas de historial** y servidor inalcanzable; **todos los usuarios navegan con `guacadmin`** (sin atribución de persona); y el **mapeo equipo↔conexión cubre el 6,8 %**. El embudo y la tasa de fallo requieren la tabla `fct_intento_conexion`, que no existe. Ver el bloque B para el desglose completo. --- ## DB-06 · Ocupación por horas 🟡 **Objetivo.** Localizar con precisión quirúrgica las franjas saturadas y las franjas muertas. **Usuarios.** Coordinador de Laboratorios, Director de Infraestructura, Director Académico. **KPIs.** % de ocupación por franja de 30 min · franja pico y franja valle · **índice de concentración** (qué % de la demanda cabe en las 3 franjas más cargadas) · horas ociosas por franja · demanda rechazada por franja 🔴. **Gráficas.** (a) Heatmap 7 días × 24 h de **% de ocupación**, con selector para alternar entre «conteo» y «porcentaje» (son dos historias distintas). (b) Perfil horario superpuesto por canal — la evidencia de producción es contundente: reservas de aula con picos a las 7 y 9 (62,2 %) frente a práctica libre con curva **plana**. (c) Barras de horas ofertadas / reservadas / usadas por franja. **Filtros.** Periodo, Sede, Categoría, **Canal** (obligatorio), Tipo de solicitante. **Drill-down.** Franja → espacios ocupados en ella → reservas. **Alertas.** Franja con ocupación >90 % durante 2 semanas; franja con <10 % durante 4 semanas. **Acciones sugeridas.** Cerrar franjas de baja demanda (ahorro de monitor); abrir capacidad en las pico; **desplazar demanda con incentivos** a las franjas 14:00–17:00, que en producción concentraron sólo el 3,9 %. **Factibilidad.** 🟡. El conteo es 🟢. Dos correcciones obligatorias: la **dimensión de franja debe definirse por rangos, no por igualdad** (hay horas no canónicas como `22:21:49` provenientes de `NOW()`), y **el mapa de ocupación actual subestima las agendas multi-hora** porque agrupa por clave `HH:MM-HH:MM` exacta en lugar de por solapamiento. --- ## DB-07 · Ocupación por días 🟢 **Objetivo.** Dimensionar personal y horarios de apertura por día de la semana y detectar la estacionalidad real. **Usuarios.** Coordinador de Laboratorios, Jefe de Servicios Generales, Recursos Humanos. **KPIs.** Reservas y horas por día de la semana · **% de operación del sábado** (dato real de producción: 13,4 % — un dashboard de semana de 5 días subestima la operación en un octavo) · día pico · **relación pico/valle mensual** (real: 17:1) · días hábiles efectivos del periodo (descontando festivos y bloqueos). **Gráficas.** (a) Barras por día de la semana con la media como referencia. (b) Calendario anual tipo *heatmap* con festivos y recesos marcados. (c) Serie mensual con las semanas de parciales y finales señaladas. **Filtros.** Periodo, Sede, Categoría, Canal. **Drill-down.** Día de la semana → fecha concreta → reservas del día. **Alertas.** Día con operación por debajo del 20 % de la media → revisar apertura. Fin de semana con demanda creciente → revisar cobertura de personal. **Acciones sugeridas.** Ajustar turnos; cerrar los días de baja demanda; **dimensionar personal por semana, no por promedio anual** (con 17:1 de pico/valle, el promedio anual garantiza colapso en marzo y ociosidad en diciembre). **Factibilidad.** 🟢 hoy, con la advertencia de que `festivos` sólo tiene 2026 y no tiene tipo ni sede. --- ## DB-08 · Dashboard por facultades 🔴 **Objetivo.** Repartir costos y capacidad entre unidades académicas con evidencia, y darle a cada decano su propio espejo. **Usuarios.** Rector, Vicerrector Académico, Decanos, Director Financiero. **KPIs.** Horas consumidas por facultad · **% del total institucional** · personas-hora · usuarios únicos por facultad y **% de cobertura de su población** · tasa de no-show por facultad · **horas desperdiciadas por facultad** (y su coste) · índice de equidad de acceso (Gini entre facultades) · coste imputado por facultad. **Gráficas.** (a) Treemap de horas por facultad → programa → espacio. (b) Barras 100 % apiladas de horas por tipo de espacio dentro de cada facultad. (c) Dispersión: población de la facultad vs. horas consumidas, con la diagonal de equidad — **una sola imagen que muestra qué facultad está sobre-servida y cuál sub-servida**. (d) Ranking de facultades por tasa de no-show con el coste asociado. **Filtros.** Periodo, Sede, Facultad, Tipo de espacio, Nivel (pregrado/posgrado). **Drill-down.** Facultad → programa → docente/estudiante → reserva. **Alertas.** Facultad con no-show >2× la media institucional; facultad con cobertura <10 % de su población; facultad que concentra >40 % de un recurso escaso. **Acciones sugeridas.** Imputar costos; renegociar cupos; abrir oferta específica para la facultad sub-servida. **Factibilidad.** 🔴 **bloqueado**. `areas_universitarias` tiene 0 filas y `agendas.IdAreaUni` está mal mapeado (16/16 huérfanas). **No hay tabla `facultades`.** Habilitador 3. Es el dashboard con mayor valor comercial y el que hoy está más lejos: **es la conversación que se tiene con quien tiene presupuesto.** --- ## DB-09 · Dashboard por programas 🔴 **Objetivo.** Entender qué programas académicos consumen qué recursos, para planear oferta y para justificar inversión por programa. **Usuarios.** Decanos, Directores de Programa, Vicerrector Académico, Acreditación. **KPIs.** Horas y sesiones por programa · usuarios únicos y **% de estudiantes del programa que usaron el servicio** · promedio de horas por estudiante · software más demandado por programa · **top 5 espacios por programa** · tasa de no-show por programa. **Gráficas.** (a) Barras horizontales de horas por programa con el número de usuarios únicos como etiqueta. (b) Matriz programa × categoría de espacio. (c) Matriz programa × software demandado (insumo directo para negociar licencias). (d) Serie por semestre para ver crecimiento por programa. **Filtros.** Periodo, Facultad, Programa, Nivel, Sede. **Drill-down.** Programa → estudiante → reserva → equipo. **Alertas.** Programa con crecimiento >50 % semestre a semestre → anticipar capacidad. Programa con 0 uso → revisar si el servicio le es visible. **Acciones sugeridas.** Ajustar oferta de laboratorio por programa; comprar licencias donde hay demanda concentrada; incluir el dato en informes de acreditación. **Factibilidad.** 🔴. `clientes.Programa` es texto libre con cardinalidad casi 1:1. El único consumidor actual (`getLabUsoPorPrograma`) agrupa por esa cadena. **A escala real producirá cientos de variantes casi-duplicadas.** Habilitador 3. Nota histórica que conviene decir al cliente: en la generación anterior existía la tabla `programas` y **el cliente nunca la alimentó** (3 filas). Recuperar el catálogo sólo tiene sentido junto a una sincronización académica real. --- ## DB-10 · Dashboard por sedes 🟡 **Objetivo.** Comparar el desempeño de campus y detectar desequilibrios de capacidad entre sedes. **Usuarios.** Rector, Vicerrector Administrativo, Directores de Sede. **KPIs.** Por sede: espacios activos · capacidad instalada · horas ofertadas / reservadas / usadas · % de ocupación · personas-hora · usuarios únicos · no-show · cancelación · **horas por espacio** (para normalizar el tamaño de la sede) · **coste por hora servida**. **Gráficas.** (a) Tabla comparativa con semáforo por columna. (b) Barras normalizadas por capacidad (una sede grande con peor porcentaje puede estar mejor gestionada). (c) Serie por sede superpuesta. (d) Mapa si hay geolocalización 🔴. **Filtros.** Periodo, Sede, Categoría. **Drill-down.** Sede → edificio 🔴 → espacio → reserva. **Alertas.** Diferencia >25 puntos de ocupación entre sedes; sede con caída sostenida. **Acciones sugeridas.** Redistribuir equipos entre sedes; replicar prácticas de la sede líder; ajustar inversión. **Factibilidad.** 🟡. `sedes` es la dimensión más limpia del sistema (3 filas, integridad verificada). Dos advertencias severas: **la sede se referencia con cinco tipos de datos distintos** (`tinyint`, `smallint`, `int`, `varchar(20)`, `varchar(500)` CSV), y **en la producción anterior el 100 % de las transacciones fue de la Sede 1** — la multi-sede nunca fue real. Antes de vender este dashboard hay que verificar que el cliente opere de verdad en varias sedes, o el gráfico será una barra al 100 %. --- ## DB-11 · Capacidad instalada 🔴 **Objetivo.** Saber qué tiene la institución, dónde está, cuánto vale y cuánta capacidad horaria representa. Es la línea base de todo lo demás. **Usuarios.** Director de Infraestructura, Director TIC, Director Financiero, Planeación. **KPIs.** Espacios activos · **puestos totales** · **horas-puesto ofertadas por semana** · equipos activos · equipos con acceso remoto y **% de cobertura de mapeo** · valor del parque · m² 🔴 · **densidad puestos/m²** 🔴 · capacidad por edificio y piso 🔴 · antigüedad media del parque 🔴. **Gráficas.** (a) Sunburst Sede → Edificio → Piso → Espacio → Puestos. (b) Barras de horas-puesto ofertadas por categoría. (c) Distribución del valor del parque por sede y estado. (d) Pirámide de antigüedad de equipos con la línea de vida útil. **Filtros.** Sede, Edificio, Categoría, Tipo de equipo, Estado. **Drill-down.** Edificio → espacio → equipo → ficha del activo. **Alertas.** Espacio activo sin inventario asociado; equipo sin ubicación; **cobertura de mapeo Guacamole <90 %** (hoy 6,8 %, y es un KPI de calidad de datos de altísimo valor y coste nulo); equipos con vida útil vencida. **Acciones sugeridas.** Completar el inventario; planear reposición; justificar presupuesto de infraestructura. **Factibilidad.** 🔴. Falta lo esencial: **no hay edificio** (la columna fue eliminada deliberadamente por una migración), **no hay piso ni salón**, **no hay m² en ninguna tabla**, y `activos` está vacía. La generación anterior tenía 21 edificios y 46 salones con capacidad — **es material recuperable, no invención**. Habilitadores 4 y 6. --- ## DB-12 · Demanda vs. oferta 🔴 **Objetivo.** Cuantificar la demanda que la institución **no está atendiendo**. Es el dashboard que justifica ampliar capacidad. **Usuarios.** Rector, Director de Infraestructura, Director TIC, Planeación. **KPIs.** Horas ofertadas vs. solicitadas vs. atendidas · **demanda insatisfecha** = intentos rechazados por cupo lleno + entradas en lista de espera + búsquedas sin resultado 🔴 · **índice de presión** por espacio y franja (solicitudes / cupos) · % de solicitudes atendidas en la primera opción · tiempo hasta el primer hueco disponible. **Gráficas.** (a) Doble área ofertada vs. demandada por franja, con el área de déficit sombreada. (b) Heatmap de índice de presión. (c) Ranking de espacios con mayor demanda insatisfecha. (d) Serie de lista de espera con tasa de conversión. **Filtros.** Periodo, Sede, Categoría, Franja. **Drill-down.** Franja deficitaria → intentos rechazados → clientes afectados → programa. **Alertas.** Índice de presión >1,5 en cualquier franja; lista de espera creciente 3 semanas seguidas; espacio con >20 rechazos/mes. **Acciones sugeridas.** Abrir franjas nuevas; replicar el espacio saturado; ampliar cupos; desplazar demanda con incentivos. **Factibilidad.** 🔴 y es el hueco analítico nº 5 de la Parte 3. **Los intentos de reserva rechazados no se persisten en ninguna parte**: las validaciones fallidas sólo producen un mensaje volátil en pantalla. La lista de espera es código sin tabla. **Sin el evento «intento fallido» no hay dashboard de demanda insatisfecha.** Habilitador «eventos de negocio» (Parte 7, E1). --- ## DB-13 · Reservas canceladas 🟡 **Objetivo.** Reducir la cancelación entendiendo quién cancela, cuándo, por qué, y cuánta capacidad se recupera. **Usuarios.** Coordinador de Laboratorios, Director Académico, Jefe de Servicio. **KPIs.** **Tasa de cancelación real** (universo unificado) · cancelaciones por canal (portal vs. administrador — el único campo con catálogo cerrado y confiable) · **antelación media** y distribución en buckets (Tardía <2 h / Mismo día / Anticipada) · horas liberadas · **% de horas liberadas efectivamente re-reservadas** · cancelaciones sobre reservas ya confirmadas vs. abandono de pre-reserva · **cancelaciones post-entrega** (anomalía operativa: debería ser ~0) · % sin motivo declarado. **Gráficas.** (a) Serie de tasa de cancelación con el objetivo institucional. (b) Distribución de antelación con la línea de la ventana configurada (`DiasCancelar`/`HorasCancelar`) — **la comparación que responde si la política funciona**. (c) Sankey estado original → cancelación por canal. (d) Barras de motivos tipificados con «Sin motivo» destacado. (e) Recuperación: horas liberadas vs. re-reservadas. **Filtros.** Periodo, Sede, Categoría, Canal, Tipo de solicitante, Antelación. **Drill-down.** Canal → cliente → reserva cancelada → historial del cliente. **Alertas.** Tasa >15 %; cancelaciones tardías >30 % del total; cliente con >3 cancelaciones tardías en 30 días; **cancelación después de la entrega** (uso indebido de la cancelación administrativa como borrado). **Acciones sugeridas.** Endurecer la ventana en los espacios de mayor cancelación tardía; introducir catálogo de motivos; notificar a la lista de espera; **distinguir reagendamiento de cancelación neta** (hoy toda cancelación se cuenta como pérdida de demanda). **Factibilidad.** 🟡 con un requisito no negociable: **el universo debe ser `citas` ∪ `citas_canceladas`**. Los KPIs actuales cuentan `Estado=2` y reportan cero. Y hay que añadir el catálogo de motivos: hoy `CanceladaMotivo` es texto libre autorrellenado. --- ## DB-14 · Reservas rechazadas 🟡 **Objetivo.** Separar tres hechos que hoy comparten un solo código de estado, y medir el desempeño del equipo de aprobación. **Usuarios.** Jefe de Servicio, Coordinador, Director TIC. **KPIs.** **Rechazos reales** (`Estado=5 AND NegadoPorUserId IS NOT NULL`) · **expiraciones por no-decisión** (`Estado=5 AND NegadoPorUserId IS NULL`) — la métrica que mide incumplimiento del equipo, no del usuario · tasa de rechazo · tiempo medio hasta la decisión · **% de solicitudes que expiran sin respuesta** · rechazos por motivo · rechazos por espacio y por solicitante. **Gráficas.** (a) **Barras apiladas rechazo vs. expiración por semana** — la separación es el corazón de este dashboard. (b) Distribución del tiempo hasta la decisión con la línea de SLA. (c) Motivos de rechazo tipificados. (d) Matriz espacio × motivo. **Filtros.** Periodo, Sede, Espacio, Operador, Motivo. **Drill-down.** Motivo → solicitud → solicitante → historial. **Alertas.** **Cualquier expiración por no-decisión es una alerta** (es servicio no prestado por omisión); tasa de rechazo >20 % en un espacio; solicitud pendiente a menos de 24 h de su franja. **Acciones sugeridas.** Reasignar aprobadores; automatizar la aprobación de casos de bajo riesgo; revisar por qué un espacio concentra rechazos. **Factibilidad.** 🟡. El dato está disponible hoy; el problema es que **el reporte actual no aplica el discriminante** y por tanto infla los rechazos con barridos del cron. Corregirlo es una cláusula `WHERE`. Y falta un catálogo de motivos: `NegadoObservacion` es texto libre. --- ## DB-15 · Equipos más utilizados 🟡 **Objetivo.** Identificar los equipos que soportan la carga real, para protegerlos con mantenimiento y para justificar reposición. **Usuarios.** Coordinador de Laboratorios, Director TIC, Compras. **KPIs.** Top N por horas y por sesiones · **% del uso total concentrado en el top 10** (en producción: 80 % en 10 de 764) · horas por equipo vs. media del parque · usuarios distintos por equipo · días desde el último mantenimiento 🔴 · **horas acumuladas de vida** 🔴. **Gráficas.** (a) Barras horizontales del top 20 con la media y el p90 marcados. (b) Curva de Pareto acumulada. (c) Serie del top 5 en el tiempo (¿el mismo equipo lleva un año liderando?). (d) Tabla con recomendación por equipo. **Filtros.** Periodo, Sede, Laboratorio, Tipo, Métrica (horas / sesiones / usuarios). **Drill-down.** Equipo → sesiones → reservas → clientes. **Alertas.** Equipo >150 % de la media → preventivo anticipado; **concentración del top 10 por encima del 50 %** → la asignación automática no está balanceando. **Acciones sugeridas.** Rotar la asignación; preventivo prioritario; usar el dato como base de la cotización de reposición. **Factibilidad.** 🟡. `ReportesModel::getRecursosUso` ya lo calcula sobre `agendas_recursos` — es **tiempo agendado**, no usado, y no cubre `activos` ni las sesiones remotas. --- ## DB-16 · Equipos nunca utilizados 🟡 **Objetivo.** Recuperar capital inmovilizado. Es el dashboard con retorno más inmediato y más fácil de construir. **Usuarios.** Director TIC, Director Financiero, Coordinador. **KPIs.** Equipos con 0 uso en el periodo · **valor inmovilizado** · días desde el último uso · equipos activos y publicados pero sin uso · **conexiones remotas nunca usadas** · equipos con `CodigoGuacamole` inválido (hoy 4 de 8) · espacios activos sin ninguna reserva. **Gráficas.** (a) Barras de conteo y valor de equipos ociosos por sede y tipo. (b) Histograma de días sin uso. (c) Tabla accionable: equipo · ubicación · valor · días sin uso · **causa probable** (no publicado / sin permisos / averiado / duplicado / mal mapeado). **Filtros.** Periodo, Sede, Laboratorio, Tipo, Umbral de días sin uso. **Drill-down.** Equipo → configuración del recurso → agenda que lo contiene → publicación en el portal. **Alertas.** Equipo activo con >60 días sin uso; espacio publicado con 0 reservas en 30 días (en producción: **991 de 1.396 agendas nunca se usaron**); conexión remota creada y nunca usada. **Acciones sugeridas.** Reubicar; dar de baja; corregir publicación o permisos; **limpiar el catálogo** — y presentar el conteo de recursos configurados sin uso como hallazgo de limpieza, no diluirlo en el promedio de ocupación. **Factibilidad.** 🟡 y es la **fruta más baja del árbol**: `LEFT JOIN ... WHERE citas.Id IS NULL` sobre `agendas_recursos` funciona hoy. El «valor inmovilizado» requiere `activos` poblada. --- ## DB-17 · Horarios pico 🟢 **Objetivo.** Dimensionar personal, soporte y apertura con base en la demanda concentrada. **Usuarios.** Coordinador de Laboratorios, Jefe de Servicios, Recursos Humanos, Mesa de Ayuda. **KPIs.** Franja pico y su % del total · **índice de concentración** (top 3 franjas / total) · pico de concurrencia y hora en que ocurre · ratio pico/valle · **franjas con demanda por encima de la capacidad** · pico por canal. **Gráficas.** (a) Perfil horario con banda de percentiles 25–75 por día de la semana. (b) **Curva de concurrencia por barrido de eventos** (la técnica correcta: `+1` en cada inicio, `−1` en cada fin, acumulado ordenado; aplicando los `−1` primero en los empates). (c) Comparación del perfil entre semestres. (d) Perfil separado por canal. **Filtros.** Periodo, Sede, Categoría, Canal, Día de la semana. **Drill-down.** Franja pico → espacios → reservas → clientes. **Alertas.** Nuevo pico histórico; concentración creciente (mayor riesgo operativo); pico que se desplaza de hora (señal de cambio en la malla académica). **Acciones sugeridas.** Reforzar personal en el pico; ofrecer incentivos para desplazar demanda al valle; ajustar horario de apertura. **Factibilidad.** 🟢 con dos advertencias que hay que escribir en la propia pantalla: la dimensión de franja debe ser por rangos, y **este perfil describe la malla de horarios académicos, no el comportamiento espontáneo del usuario** (62,2 % de reservas a las 7 y 9 en producción). Confundir ambas cosas lleva a conclusiones erróneas. --- ## DB-18 · Disponibilidad futura 🔴 **Objetivo.** Cambiar la pregunta de «qué pasó» a **«qué va a pasar»**: cuánta capacidad libre queda en los próximos 30 días y dónde. **Usuarios.** Coordinador de Laboratorios, Registro Académico, Mesa de Ayuda, Director Académico. **KPIs.** Horas libres en los próximos 7 / 30 días · % de ocupación proyectada · **espacios sin ningún hueco disponible** · **próximo hueco disponible por espacio** (dato de altísimo valor para atención al usuario) · horas comprometidas por series recurrentes 🔴 · impacto de bloqueos programados. **Gráficas.** (a) Calendario prospectivo de 30 días con semáforo de ocupación por día. (b) Matriz espacio × día con celdas de disponibilidad. (c) Barras de horas libres vs. comprometidas por espacio. (d) Línea de tiempo de bloqueos programados con su impacto en horas. **Filtros.** Horizonte (7/15/30/60 días), Sede, Categoría, Espacio, Franja. **Drill-down.** Día → espacio → franjas libres → **crear reserva desde el dashboard**. **Alertas.** Espacio sin disponibilidad en los próximos 7 días; bloqueo programado que afecta a reservas ya confirmadas (**hoy el bloqueo no cancela ni avisa a las reservas existentes** — hueco funcional real); ocupación proyectada >90 %. **Acciones sugeridas.** Abrir capacidad extraordinaria; reprogramar bloqueos a franjas de baja demanda; avisar proactivamente a los afectados. **Factibilidad.** 🔴. Requiere el habilitador 4 (capacidad ofertada) y, para las series, las migraciones pendientes. **Es el dashboard que convierte la herramienta de reportes en herramienta de gestión**, y también el único de la lista que un usuario operativo abriría a diario. --- ## DB-19 · Cumplimiento 🟡 **Objetivo.** Medir si las reglas que la institución definió se están cumpliendo — por el usuario y por la administración. **Usuarios.** Jefe de Servicio, Director TIC, Auditoría Interna, Secretaría General. **KPIs.** - *Del usuario:* % de asistencia · % de check-in dentro de la tolerancia 🔴 · % de devoluciones a tiempo · % de cancelaciones dentro de la ventana · reservas por encima de la cuota 🔴. - *De la administración:* **% de solicitudes decididas dentro del SLA** · % de expiraciones por no-decisión · % de reservas notificadas efectivamente 🔴 · % de bloqueos resueltos con motivo registrado. - *Del dato:* % de reservas con cliente vinculado · con recurso identificado · con entrega registrada · **con código de reserva** (hoy 68 % sin `CodigoQr`) · **adherencia al proceso** = `Estado=3` con `EstadoEntrega=0` (en la base viva 5 de 7 finalizadas no tienen entrega registrada: **71 % se cierra «a dedo»**). **Gráficas.** (a) Tablero de cumplimiento con semáforo por regla y su tendencia. (b) Barras de cumplimiento por espacio y por operador. (c) Serie de adherencia al proceso. (d) Cascada de fugas de cumplimiento. **Filtros.** Periodo, Sede, Espacio, Operador, Regla. **Drill-down.** Regla → casos de incumplimiento → reserva/operador responsable. **Alertas.** Cumplimiento de SLA <80 %; adherencia al proceso <70 %; cualquier expiración por no-decisión; caída del % de reservas con cliente vinculado. **Acciones sugeridas.** Capacitar operadores; hacer obligatorios los campos que hoy se omiten; automatizar la aprobación de bajo riesgo; **corregir el proceso antes de corregir el dashboard**. **Factibilidad.** 🟡, y es el dashboard **más honesto y más incómodo** de los 30: mide la salud del proceso, no del negocio. La mitad de sus KPIs son calculables hoy y revelan problemas operativos reales. Los de check-in y notificación son 🔴 (no existe check-in; `alertas_email` no tiene `IdCita`). --- ## DB-20 · Productividad 🟡 **Objetivo.** Medir el rendimiento del equipo que opera el servicio, y la eficiencia del servicio en sí. **Usuarios.** Jefe de Servicio, Director TIC, Recursos Humanos. **KPIs.** *Por operador:* decisiones de aprobación · tiempo medio de decisión · % de cumplimiento de SLA · entregas y recepciones registradas · préstamos atendidos · cancelaciones administrativas ejecutadas. *Del servicio:* **personas-hora atendidas por hora-hombre** · reservas gestionadas por operador y día · **% de operación en autoservicio vs. mostrador** 🔴 (el KPI de eficiencia más importante: cada reserva de autoservicio es una hora-hombre ahorrada) · tiempo medio de atención en mostrador 🔴. **Gráficas.** (a) Tabla de operadores con las 6 métricas y su percentil. (b) Barras de carga por operador y por día (para detectar concentración de trabajo). (c) **Serie de % de autoservicio** — la curva que demuestra el ROI del portal. (d) Dispersión volumen vs. tiempo de respuesta por operador. **Filtros.** Periodo, Sede, Operador, Tipo de tarea. **Drill-down.** Operador → decisiones → reservas afectadas. **Alertas.** Operador con SLA <70 %; carga desbalanceada >2× entre operadores; caída del % de autoservicio. **Acciones sugeridas.** Redistribuir carga; formar a quien está por debajo; empujar el autoservicio con comunicación. **Factibilidad.** 🟡. `getAprobacionesPorOperador` ya calcula la parte de aprobaciones. **Advertencia crítica derivada de la producción:** `UsuarioRegistro=1` en el 99,8 % de las filas — **el usuario 1 no es una persona, es el proceso batch**. Cualquier análisis de productividad debe separar actores humanos de actores sistema antes de agregar, o producirá un ranking de ficciones. Y el % de autoservicio requiere promover el canal de origen a columna (hoy vive dentro de un JSON). --- ## DB-21 · Uso por estudiante 🔴 **Objetivo.** Entender el comportamiento individual para segmentar, fidelizar y sancionar con justicia. **Usuarios.** Coordinador, Bienestar Universitario, Decanos, Mesa de Ayuda. **KPIs.** Estudiantes únicos atendidos · **% de cobertura sobre la población matriculada** 🔴 · horas por estudiante (media, mediana, p95) · **distribución de intensidad** (1 uso / 2–5 / 6–20 / +20) · tasa de retorno · no-show y cancelación individuales · estudiantes sancionados · **estudiantes de alto valor** (uso alto y cumplimiento alto) y **de alto riesgo** (uso alto y no-show alto). **Gráficas.** (a) Histograma de intensidad de uso — el hallazgo de producción es contundente: **de 941 estudiantes, el 54,2 % usó el servicio una única vez**. (b) Matriz 2×2 uso × cumplimiento con los cuatro cuadrantes accionables. (c) Cohortes de retención por mes de primer uso. (d) Curva de Lorenz de la demanda estudiantil. **Filtros.** Periodo, Sede, Facultad, Programa, Nivel, Intensidad. **Drill-down.** Segmento → estudiante → historial completo → sanciones. **Alertas.** Estudiante a un no-show del bloqueo automático (**alerta preventiva: hoy el sistema sanciona sin haber avisado nunca**); estudiante con >20 reservas y >30 % de no-show; caída de la tasa de retorno. **Acciones sugeridas.** Campaña de reactivación a los de un solo uso; aviso preventivo antes de sancionar; reconocimiento a los de alto valor. **Factibilidad.** 🔴 por dos razones: **el 12 % de las reservas no tiene cliente vinculado** (y los *walk-in* casi nunca lo tienen), `clientes.Documento` no es único, y **no hay fecha de vinculación** → sin cohortes. Requiere además el total de matriculados como parámetro externo. **Y es el dashboard con mayor sensibilidad de privacidad**: debe tener agregación mínima obligatoria y acceso restringido por rol. --- ## DB-22 · Uso por docente 🔴 **Objetivo.** Ver qué docentes usan los recursos, con qué intensidad y con qué cumplimiento, para planear la oferta académica. **Usuarios.** Decanos, Directores de Programa, Vicerrector Académico. **KPIs.** Docentes activos · horas reservadas por docente · **horas por docente y por asignatura** 🔴 · reservas recurrentes vs. puntuales 🔴 · tasa de no-show docente (**políticamente delicada y operativamente crítica**: un no-show docente desperdicia un aula completa) · espacios y software más solicitados por docente · % de docentes que usan el autoservicio. **Gráficas.** (a) Ranking de docentes por horas con su tasa de cumplimiento como color. (b) Serie de horas docentes por semana con las semanas de parciales marcadas. (c) Matriz docente × espacio. (d) Comparación docente vs. estudiante en perfil horario. **Filtros.** Periodo, Facultad, Programa, Docente, Tipo de espacio. **Drill-down.** Docente → serie recurrente → instancias → asistencia. **Alertas.** Docente con >3 no-shows en el semestre; docente que reserva y nunca usa; docente con reservas fuera de su facultad. **Acciones sugeridas.** Conversación de decanatura con el docente; convertir reservas repetidas en series recurrentes; ajustar la asignación de aulas de la facultad. **Factibilidad.** 🔴. `clientes.Tipo='Docente'` existe y **no se usa en ninguna gráfica actual** — ese primer paso es 🟢. Lo demás requiere: la dimensión académica (habilitador 3), la tabla de recurrencias (migraciones pendientes) y el concepto de asignatura, que no existe. **Advertencia de uso:** en producción, los usuarios de cola larga no eran docentes sino coordinadores reservando en nombre de terceros. Sin marcar la reserva por delegación, este dashboard atribuye mal. --- ## DB-23 · Uso por dependencia 🔴 **Objetivo.** Medir el consumo de las áreas administrativas (Bienestar, Talento Humano, Extensión, Comunicaciones) que hoy se mezcla con el académico. **Usuarios.** Vicerrector Administrativo, Jefes de dependencia, Director Financiero. **KPIs.** Horas por dependencia · **% del total institucional consumido por administración vs. academia** · tipos de espacio usados (típicamente salas de juntas y auditorios) · anticipación media (las dependencias planean distinto) · tasa de cancelación por dependencia · **coste imputado**. **Gráficas.** (a) Barras de horas por dependencia. (b) Torta academia vs. administración vs. externos. (c) Matriz dependencia × tipo de espacio. (d) Serie mensual (la administración tiene estacionalidad propia: consejos, grados, inducciones). **Filtros.** Periodo, Sede, Dependencia, Tipo de espacio. **Drill-down.** Dependencia → persona → reserva. **Alertas.** Dependencia que concentra >30 % de un recurso escaso; reservas administrativas en franjas de alta demanda académica. **Acciones sugeridas.** Reservar franjas protegidas para academia; imputar costos a las dependencias; crear un pool de salas exclusivo para administración. **Factibilidad.** 🔴. La dependencia hoy está **escondida dentro de `clientes.Programa`** mezclada con programas académicos y cargos de monitoría ('Bienestar Universitario', 'Decanatura Ingeniería', 'Dirección Académica' conviven con 'Medicina' y 'Monitor laboratorio informática'). Y `usuarios.Dependencia` es texto libre. **Separar las tres semánticas de ese campo es el trabajo previo**, y es el mismo habilitador 3. --- ## DB-24 · Incidentes 🔴 **Objetivo.** Convertir las incidencias dispersas en una serie gestionable: qué se rompe, dónde, cuánto tarda en resolverse y a quién afecta. **Usuarios.** Mesa de Ayuda, Coordinador de Laboratorios, Director TIC. **KPIs.** Incidentes abiertos / cerrados · **backlog y su antigüedad** · MTTR 🔴 · % resueltos en el SLA 🔴 · incidentes por espacio y por equipo · **top equipos con más incidencias** · incidentes por causa (avería / daño / pérdida / software / red / acceso) · **incidentes que causaron indisponibilidad** y horas afectadas. **Gráficas.** (a) Serie de abiertos vs. cerrados con el backlog acumulado. (b) Pareto de causas. (c) Mapa de calor equipo × tipo de incidente. (d) Distribución del tiempo de resolución con la línea de SLA. (e) Barras de horas de servicio perdidas por incidente. **Filtros.** Periodo, Sede, Espacio, Tipo, Prioridad, Estado, Responsable. **Drill-down.** Causa → incidente → equipo → reservas afectadas → clientes afectados. **Alertas.** Backlog creciente 2 semanas; incidente crítico abierto >24 h; equipo con >3 incidentes en 30 días → candidato a reposición; incidente que afecta a reservas ya confirmadas. **Acciones sugeridas.** Escalar; reponer el equipo reincidente; avisar a los afectados; ajustar el plan preventivo. **Factibilidad.** 🔴 con un hallazgo que cambia el enfoque: **`clientes_tickets` no es la fuente de incidencias.** Está vacía, su ciclo de vida está truncado (no existe UI para responder), no tiene `FechaCierre` (**el SLA no es medible ni estructuralmente**) y no tiene `IdCita`/`IdAgenda`/`IdActivo` (una incidencia no es atribuible a ningún recurso). **La historia real de incidencias de la institución vive en `clientes_bloqueos.Motivo`**: en producción, 226 casos de devolución con daño y 101 de elemento no devuelto, descritos en texto libre. Construir este dashboard exige (a) completar el ciclo de tickets, (b) añadir `FechaPrimeraRespuesta`/`FechaCierre` y la referencia al recurso, y (c) un catálogo de causas. --- ## DB-25 · Mantenimiento 🔴 **Objetivo.** Gestionar el mantenimiento del parque con evidencia: qué se interviene, cuánto cuesta, cuánto tiempo está fuera de servicio y si el plan preventivo se cumple. **Usuarios.** Director TIC, Coordinador de Laboratorios, Director Financiero, Proveedores. **KPIs.** Órdenes abiertas / cerradas · **MTTR** · **MTBF** · **% de disponibilidad técnica (uptime)** · **downtime en horas y su coste de oportunidad** · % de cumplimiento del plan preventivo · costo de mantenimiento por activo y **% sobre valor de reposición** · equipos fuera de garantía · top 10 equipos por costo acumulado. **Gráficas.** (a) Serie de disponibilidad por laboratorio con el objetivo. (b) Barras de downtime por equipo y su coste. (c) Pareto de costos por equipo y por tipo de falla. (d) Gantt de órdenes abiertas. (e) Cumplimiento del preventivo por mes. **Filtros.** Periodo, Sede, Laboratorio, Tipo de equipo, Tipo de mantenimiento, Técnico, Proveedor. **Drill-down.** Equipo → historial de órdenes → repuestos y costos → reservas afectadas. **Alertas.** Disponibilidad <95 %; orden abierta >7 días; equipo con 3 correctivos en 90 días → reponer; preventivo vencido; garantía por vencer en 30 días. **Acciones sugeridas.** Priorizar la cola técnica; decidir reponer vs. reparar con el dato de costo acumulado; reclamar garantía; renegociar con el proveedor cuyo equipo falla más. **Factibilidad.** 🔴 **completo: mantenimiento no existe.** Cero tablas con «mant», cero columnas `Marca`, `Modelo`, `Placa`, `Garantia`. Lo único que hay es el valor `activos.Estado=3` (sin fecha, motivo, responsable ni costo) y el *sniffing* de texto en la descripción del recurso. **Mínimo viable en tres piezas, en este orden** (con esto se obtienen MTTR, downtime, disponibilidad, MTBF, costo y backlog): 1. `activos_estado_historial` (`IdActivo`, `EstadoAnterior`, `EstadoNuevo`, `Motivo`, `FechaHora`, `IdUsuario`) + escritura obligatoria en cada cambio de estado. **Es la pieza crítica: sin ella no hay downtime ni disponibilidad, para nada.** 2. `activos_mantenimiento_ordenes` reducida a `IdActivo`, `Tipo`, `Estado`, `FechaReporte`, `FechaInicio`, `FechaFin`, `Diagnostico`, `IdTecnico`, `CostoTotal`. 3. Botón **«Reportar falla»** en la tarjeta del tablero de préstamos y en la ficha del activo, que cree la orden y ponga la unidad en mantenimiento **por estado, no por texto en la descripción**. --- ## DB-26 · Crecimiento histórico 🟡 **Objetivo.** Demostrar la evolución del servicio en el tiempo — el dashboard que se usa para renovar el contrato y para el informe de gestión. **Usuarios.** Rector, Director TIC, Planeación, Acreditación. **KPIs.** Reservas, horas y personas-hora por mes y por semestre · **CAGR del servicio** · usuarios únicos acumulados y nuevos por periodo · espacios y equipos incorporados · **% de adopción del autoservicio en el tiempo** 🔴 · % de servicio remoto en el tiempo 🔴 · hitos (nuevos módulos, nuevas sedes). **Gráficas.** (a) Serie mensual de horas con línea de tendencia y **anotaciones de hitos**. (b) Barras por semestre con crecimiento porcentual etiquetado. (c) Área acumulada de usuarios únicos con nuevos vs. recurrentes. (d) Serie de mix de canales. **Filtros.** Granularidad (mes/semestre/año), Sede, Categoría, Canal. **Drill-down.** Semestre → mes → semana → reservas. **Alertas.** Crecimiento negativo dos semestres seguidos; caída >30 % en un mes que no sea de receso. **Acciones sugeridas.** Documentar el crecimiento en el informe de gestión; investigar caídas; correlacionar hitos con inflexiones. **Factibilidad.** 🟡 con **una advertencia obligatoria** derivada de la arqueología de producción: la serie de la generación anterior muestra un patrón que parece «mejora de gestión» y **es abandono del sistema** (cancelaciones 2022: 2.599 → 2023: 2.954 → 2024: 1.231 → 2025: 2; práctica libre pasó de 405 sesiones en marzo de 2024 a 1 en mayo). **Un dashboard de crecimiento debe distinguir «bajó la demanda» de «se dejó de usar el sistema»**, y la forma de hacerlo es cruzar con la actividad de operadores y con la cobertura de los datos. Si no, se presenta un colapso de adopción como un éxito de eficiencia. --- ## DB-27 · Comparativo por semestre 🔴 **Objetivo.** Comparar manzanas con manzanas. En una universidad, la única comparación válida es contra el mismo periodo del semestre equivalente. **Usuarios.** Vicerrector Académico, Decanos, Director TIC, Planeación. **KPIs.** Todos los KPIs núcleo, en formato semestre actual vs. anterior vs. mismo semestre del año pasado: horas, ocupación, no-show, cancelación, usuarios únicos, personas-hora, % remoto, SLA de aprobación. Más **índice de comparabilidad** (días hábiles equivalentes, para no comparar un semestre de 16 semanas con uno de 14). **Gráficas.** (a) Tabla de doble comparación con variación absoluta y porcentual y semáforo. (b) **Series superpuestas alineadas por semana del semestre** (no por fecha calendario — es la clave para que la comparación tenga sentido). (c) Barras agrupadas por semestre y categoría. (d) Radar de los 8 KPIs núcleo entre semestres. **Filtros.** Semestres a comparar, Sede, Facultad, Categoría. **Drill-down.** KPI → semana del semestre → espacios → reservas. **Alertas.** Deterioro >10 % en cualquier KPI núcleo contra el semestre equivalente. **Acciones sugeridas.** Explicar las desviaciones en el comité; ajustar la oferta del próximo semestre; documentar para acreditación. **Factibilidad.** 🔴 **bloqueado por la ausencia de la dimensión tiempo con periodo académico.** No existe tabla `periodos_academicos`, y sin ella «semestre» no es una entidad. La ruta es corta: una tabla `periodos_academicos (Codigo 'AAAA-1', FechaInicio, FechaFin)` y un join por rango — **no requiere tocar `citas`**. Habilitador 2. --- ## DB-28 · Tendencias 🟡 **Objetivo.** Ver la dirección del negocio separada del ruido estacional, y detectar cambios de patrón antes de que sean obvios. **Usuarios.** Director TIC, Planeación, Rector. **KPIs.** Tendencia desestacionalizada de horas y reservas · **índice de estacionalidad por mes** (con base en la relación pico/valle real, 17:1) · media móvil de 4 semanas de los KPIs núcleo · **detección de cambio de nivel** (¿cuándo cambió el patrón?) · velocidad de crecimiento por categoría y por sede · **desplazamiento del perfil horario** en el tiempo. **Gráficas.** (a) Serie con descomposición tendencia / estacionalidad / residuo. (b) Media móvil con banda de control (±2σ) y puntos fuera de banda marcados. (c) Small multiples de tendencia por categoría. (d) Comparación del perfil horario de este semestre contra el de hace un año, superpuestos. **Filtros.** Métrica, Granularidad, Sede, Categoría, Ventana de suavizado. **Drill-down.** Punto anómalo → semana → reservas de esa semana. **Alertas.** Punto fuera de la banda de control; cambio de nivel sostenido 3 periodos; inversión de la tendencia. **Acciones sugeridas.** Investigar el punto de inflexión; ajustar previsiones; anticipar capacidad. **Factibilidad.** 🟡. Calculable con SQL y ventanas móviles, **sin necesidad de ML**. Requiere `dim_tiempo` para desestacionalizar correctamente. Es el paso natural desde el nivel descriptivo y **no requiere ninguna inversión en IA**. --- ## DB-29 · Dashboard predictivo con IA 🔴 **Objetivo.** Anticipar: cuánta demanda habrá, qué reservas se van a caer, qué equipo va a fallar. **Usuarios.** Coordinador de Laboratorios, Director TIC, Planeación. **KPIs / salidas del modelo.** 1. **Demanda prevista** por espacio, día y franja para los próximos 14 días, con intervalo de confianza. 2. **Probabilidad de no-show por reserva** (score 0–100), con los factores explicativos. 3. **Ocupación prevista** vs. capacidad, con las franjas que van a saturar. 4. **Riesgo de fallo por equipo** basado en horas acumuladas e historial de incidencias 🔴. 5. **Riesgo de abandono del servicio** por estudiante (los de un solo uso). 6. **Precisión del modelo** (MAPE de la predicción de demanda, AUC del score de no-show) — **un dashboard predictivo que no publica su propio error no es auditable y no debe existir.** **Gráficas.** (a) Serie histórica + predicción con banda de confianza. (b) Tabla de reservas próximas ordenadas por probabilidad de no-show, con acción directa. (c) Heatmap de saturación prevista. (d) Curva de calibración del modelo. (e) Gráfico de factores explicativos por predicción (transparencia). **Filtros.** Horizonte, Sede, Espacio, Categoría, Umbral de riesgo. **Drill-down.** Predicción → factores → histórico comparable → reserva concreta. **Alertas.** Saturación prevista >90 % en una franja; reserva con probabilidad de no-show >70 %; equipo con riesgo alto de fallo. **Acciones sugeridas.** Sobre-reservar controladamente las franjas de alto no-show; confirmar por correo las reservas de riesgo; adelantar mantenimiento; abrir capacidad extraordinaria. **Factibilidad.** 🔴, y con una **recomendación de arquitectura importante: el predictivo v1 no debe ser ML.** Debe ser **scoring por reglas en SQL**, materializado por un job nocturno en una tabla `clientes_riesgo` / `predicciones_demanda`: - **Probabilidad de no-show** = f(no-shows recientes del cliente, antigüedad del vínculo, tipo de usuario, franja horaria, lead time, canal). **Todos los insumos ya existen**: `countRecentNoShows` ya está implementado en `ClientReservationPolicyService`. - **Demanda prevista** = media móvil de las últimas 4 semanas del mismo día y franja, ajustada por el índice de estacionalidad del periodo académico y corregida por festivos y bloqueos. Eso es defendible, explicable, auditable y se construye con la infraestructura existente. **Y el LLM se reserva para lo que ya sabe hacer: explicar el score en lenguaje natural.** Lo que hoy no existe en absoluto: feature store, tabla de predicciones, versionado de modelo, backtesting, ni ninguna librería numérica en `vendor/`. Precondición dura: **al menos dos semestres de datos limpios**, que hoy no existen. --- ## DB-30 · Recomendaciones automáticas 🔴 **Objetivo.** No mostrar números: **mostrar decisiones**. Es el dashboard que un director abre cuando no tiene tiempo de mirar los otros 29. **Usuarios.** Director TIC, Coordinador de Laboratorios, Director de Infraestructura, Rector. **Contenido.** Una lista priorizada de recomendaciones, cada una con: **qué hacer · por qué (evidencia con enlace al dashboard que la sustenta) · impacto estimado · esfuerzo · un botón para ejecutarla o para descartarla con motivo**. Catálogo inicial de reglas (todas derivadas de hallazgos reales de esta auditoría): 1. «Cerrar la franja 14:00–16:00 del Laboratorio X: 8 % de ocupación durante 4 semanas. Ahorro estimado: 32 h-monitor/mes.» 2. «Abrir un cupo adicional en la franja 09:00 del Laboratorio Y: presión 1,8, con 14 rechazos el último mes.» 3. «Rotar los equipos PC-03 y PC-27: el primero acumula 180 % del uso medio, el segundo 12 %.» 4. «Dar de baja o reubicar 7 equipos con más de 90 días sin uso. Valor inmovilizado: $X.» 5. «Adelantar el mantenimiento preventivo de los 5 equipos con mayor uso acumulado.» 6. «Endurecer la ventana de cancelación del Auditorio A: 41 % de sus cancelaciones son tardías.» 7. «Notificar preventivamente a 12 estudiantes que están a un no-show del bloqueo automático.» 8. «Reasignar el grupo del curso Z a un aula de 30 puestos: está usando un auditorio de 200 con 12 asistentes.» 9. «Completar el mapeo Guacamole de 51 equipos: el 93 % del parque no puede ofrecerse en remoto.» 10. «Ejecutar el worker de correo: 19 notificaciones llevan N días sin salir.» 11. «Revisar la publicación de 3 espacios activos sin ninguna reserva en 30 días.» 12. «Corregir 4 códigos Guacamole inválidos que generan botones de conexión que siempre fallan.» **Gráficas.** Ninguna. Es una **bandeja de decisiones**, con tarjetas ordenadas por impacto e insignias de confianza. **Filtros.** Dominio, Impacto, Esfuerzo, Estado (nueva / aceptada / descartada / ejecutada). **Drill-down.** Recomendación → evidencia (dashboard + datos) → objeto afectado → pantalla de ejecución. **Alertas.** Recomendación de alto impacto sin atender en 7 días. **Acciones sugeridas.** Es el dashboard hecho de acciones. Lo importante es **medir la tasa de aceptación**: qué porcentaje de recomendaciones el equipo acepta. Es la métrica directa de confianza en el sistema, y el patrón ya existe en el asistente IA (`asistente_ia_acciones` con estados 0 Pendiente / 1 Ejecutada / 2 Descartada / 3 Fallida, y `FechaResolucion`). **Factibilidad.** 🔴 pero **más cerca de lo que parece**: es un motor de reglas sobre agregados, no IA. Requiere los agregados de los dashboards que lo alimentan y una tabla `recomendaciones` que **puede replicar el diseño ya probado de `asistente_ia_acciones`**. El LLM sirve para redactar la recomendación en lenguaje natural, no para decidirla. --- # BLOQUE B — Escritorio remoto: dashboards específicos **Nota de diseño.** El encargo lista 13 métricas de escritorio remoto. Convertir cada una en un dashboard independiente sería mal diseño: se obtienen 13 pantallas de una sola cifra que nadie visita. **Se consolidan en 8 dashboards coherentes**, y esta tabla mapea explícitamente dónde vive cada una de las 13 métricas solicitadas. | Métrica solicitada | Dashboard | Factibilidad | |---|---|---| | Sesiones por día | RM-01 | 🟡 | | Usuarios concurrentes | RM-02 | 🟡 | | Horas de uso | RM-01 | 🟡 | | Equipos más utilizados | RM-03 | 🟡 | | Equipos apagados | RM-04 | 🔴 | | Equipos inactivos | RM-03 | 🟡 | | Horas pico | RM-02 | 🟡 | | Disponibilidad | RM-04 | 🔴 | | Conexiones fallidas | RM-05 | 🔴 | | Tiempos promedio | RM-01 | 🟡 | | Ahorro por acceso remoto | RM-07 | 🔴 | | Ocupación física vs. remota | RM-06 | 🔴 | | Laboratorios virtuales más utilizados | RM-03 | 🟡 | --- ## RM-01 · Actividad y consumo remoto 🟡 **Objetivo.** La foto de volumen: cuánto se usa el acceso remoto. **Usuarios.** Director TIC, Coordinador. **KPIs.** Sesiones/día · horas de uso · usuarios únicos · duración media, **p50 y p95** · distribución en 6 buckets · **% de rebotes (<60 s)** · sesiones nuevas vs. recurrentes · tiempo medio entre sesiones por usuario. **Gráficas.** Serie diaria con eje denso · histograma de duración con el bucket «<5 min» destacado · barras de sesiones por semana · tabla de últimas sesiones. **Filtros.** Periodo, Laboratorio, Equipo, Protocolo, Origen de red. **Drill-down.** Día → sesión → equipo → reserva → cliente. **Alertas.** % de rebotes >15 % en un equipo (**el mejor proxy indirecto de fallo con el esquema estándar**: guacd aceptó el túnel y el usuario salió de inmediato) · caída >30 % de sesiones semana contra semana. **Acciones.** Investigar equipos con rebotes altos · ampliar el servicio en el laboratorio con más demanda. **Factibilidad.** El cálculo existe casi entero en `GuacHistorialStats` (que ya calcula mediana). Faltan p95, rebotes y nuevos vs. recurrentes. Bloqueo real: **0 filas de historial**. ## RM-02 · Concurrencia y capacidad remota 🟡 **Objetivo.** Saber cuántos usuarios simultáneos soporta el servicio y cuándo se queda sin equipos. **Usuarios.** Director TIC, Infraestructura. **KPIs.** **Concurrencia máxima y hora del pico** · concurrencia media por franja · **% de tiempo en tope de capacidad** (contra `guacamole_connection.max_connections`) · equipos ocupados simultáneamente · concurrencia por laboratorio. **Gráficas.** **Curva de concurrencia por franja de 15 min con la línea de capacidad** · heatmap hora × día de concurrencia · serie del pico diario. **Filtros.** Periodo, Laboratorio, Franja. **Drill-down.** Momento del pico → sesiones activas en ese instante → equipos. **Alertas.** Concurrencia >85 % de la capacidad · nuevo pico histórico. **Acciones.** Ampliar licencias/equipos · escalonar la oferta de franjas. **Factibilidad.** 🟡 con nota técnica: se calcula con **barrido de eventos** (`+1` en `start_date`, `−1` en `end_date`, acumulado ordenado, aplicando los `−1` primero en empates). **Precondición ineludible: sanear los `end_date` NULL antes del barrido**, o las sesiones huérfanas suman +1 eternamente y el pico será monótonamente creciente. Debe precalcularse en `agg_concurrencia_15min`: recalcularlo en cada carga es inviable. ## RM-03 · Equipos y laboratorios virtuales 🟡 **Objetivo.** Qué equipos y qué laboratorios virtuales concentran el uso remoto, y cuáles están ociosos. **Usuarios.** Coordinador, Director TIC. **KPIs.** Sesiones y horas **por `connection_id`** (no por nombre) · sesiones por grupo de conexión (= laboratorio virtual) · **días sin uso por conexión** · **conexiones nunca usadas** · mix de protocolos · balanceo real en pools · **cobertura de mapeo** (% de equipos reservables con `CodigoGuacamole` válido: hoy **6,8 %**). **Gráficas.** Barras del top de equipos · treemap laboratorio virtual → equipo · tabla de conexiones ociosas con causa probable · torta de protocolos. **Filtros.** Periodo, Laboratorio virtual, Protocolo, Estado de mapeo. **Drill-down.** Laboratorio → equipo → sesiones → reservas. **Alertas.** Conexión con 0 sesiones en 30 días · desviación fuerte en un pool balanceado (**revela equipos caídos que el balanceador descarta en silencio**) · equipo con `CodigoGuacamole` que no corresponde a ninguna conexión existente. **Acciones.** Retirar conexiones muertas · corregir permisos · completar el mapeo. **Factibilidad.** 🟡. Requiere el habilitador 5 (`GuacConnectionId` como entero) y la dimensión `dim_equipo_remoto` con SCD2 — sin ella, **renombrar una conexión huérfana todo el histórico anterior**. ## RM-04 · Disponibilidad de equipos (encendido / apagado) 🔴 **Objetivo.** Saber si los equipos están disponibles **antes** de que un estudiante lo descubra. **Usuarios.** Mesa de Ayuda, Coordinador, Director TIC. **KPIs.** **% de disponibilidad (uptime) por equipo y laboratorio** · equipos inalcanzables ahora · **MTBF / MTTR** · latencia media de establecimiento · top de equipos con más caídas · disponibilidad en horario de servicio vs. fuera. **Gráficas.** Semáforo en vivo por laboratorio (rejilla de equipos) · serie de disponibilidad diaria con el objetivo · barras de horas de indisponibilidad por equipo · distribución de latencia. **Filtros.** Laboratorio, Equipo, Periodo, Franja de servicio. **Drill-down.** Equipo → historial de sondeos → códigos de error → reservas afectadas. **Alertas.** Equipo inalcanzable con reserva confirmada en la próxima hora (**la alerta de mayor valor de todo el módulo**) · disponibilidad <95 % · laboratorio con >20 % de equipos caídos. **Acciones.** Encender remotamente (WoL) · reasignar la reserva a otro equipo · avisar al estudiante antes de que llegue · abrir orden de mantenimiento. **Factibilidad.** 🔴, **y es el más rentable de construir porque el motor ya existe**. [core/GuacdProbe.php](../../core/GuacdProbe.php) no es un ping: abre socket a `guacd:4822`, ejecuta el handshake completo con los parámetros reales de la conexión y traduce **12 códigos de estado a lenguaje de negocio** — incluidos `519` («No se encontró el equipo: revisa si está encendido»), `769` («Credenciales rechazadas») y `514`/`776` (timeouts). Está expuesto en `guacConexiones&a=testJson` y **no tiene ni un botón en las vistas, ni una tabla donde persistir, ni un cron que lo recorra**. Lo que falta es pequeño: tabla `equipos_sondeos (IdAgendaRecurso, GuacConnectionId, FechaHora, Alcanzable, CodigoEstado, LatenciaMs)` + un comando en `bin/` cada 5 min + un botón. Con eso se obtienen disponibilidad, MTBF, MTTR, semáforo en vivo y **una proxy razonable de la tasa de fallo**. ## RM-05 · Fiabilidad de la conexión (fallos) 🔴 **Objetivo.** Medir el fracaso, que es lo que el usuario recuerda. **Usuarios.** Mesa de Ayuda, Director TIC. **KPIs.** **Tasa de éxito de conexión** · intentos fallidos por causa (sin código Guacamole / fuera de ventana / estado inválido / Guacamole caído / equipo apagado / credenciales / timeout) · **embudo reserva → intento → sesión → uso efectivo (>5 min)** · equipos con >20 % de intentos fallidos (**cola de mantenimiento priorizada**) · fallos por franja horaria (**revela equipos apagados de noche**) · tiempo hasta el primer intento exitoso. **Gráficas.** Embudo con las fugas etiquetadas · Pareto de causas de fallo · heatmap equipo × causa · serie de tasa de éxito. **Filtros.** Periodo, Laboratorio, Equipo, Causa, Origen. **Drill-down.** Causa → intento → reserva → cliente → equipo. **Alertas.** Tasa de éxito <90 % · equipo con 3 fallos consecutivos · **cualquier fallo en una reserva confirmada** (es servicio prometido y no entregado). **Acciones.** Reparar el equipo · corregir la configuración · avisar al usuario · reasignar. **Factibilidad.** 🔴. **Guacamole no persiste fallos por diseño**: la fila del historial se escribe cuando el túnel ya se estableció. Requiere la tabla `fct_intento_conexion` escrita desde el lado Klee. **Y todos los puntos de escritura ya están identificados en el código**: cada retorno de error de `validateReservationRemoteWindow`, el fallo de token, la ausencia de `CodigoGuacamole`, el mismo flujo en préstamo inmediato, el éxito de redirección, y el resultado completo de `GuacdProbe::test` con su código y mensaje ya traducidos. **Es una tabla y una llamada en seis sitios.** ## RM-06 · Ocupación física vs. remota 🔴 **Objetivo.** Entender la sustitución: cuánto del servicio migró a remoto y qué significa para el espacio físico. **Usuarios.** Rector, Director de Infraestructura, Director TIC. **KPIs.** Horas presenciales vs. remotas y su mix · **% de reservas con remoto habilitado que terminaron en sesión remota real** · equipos usados sólo en remoto / sólo presencial / en ambos · ocupación física del laboratorio en las horas de alta demanda remota · **puestos físicos liberados por el remoto**. **Gráficas.** Área apilada presencial vs. remoto en el tiempo · matriz laboratorio × modalidad · dispersión ocupación física vs. remota por laboratorio. **Filtros.** Periodo, Laboratorio, Sede, Categoría. **Drill-down.** Laboratorio → equipo → sesiones por modalidad → reservas. **Alertas.** Laboratorio con demanda remota alta y ocupación física baja → **candidato a reconvertir el espacio**; equipo con 100 % de uso remoto → puede moverse a un rack. **Acciones.** Reconvertir espacio físico · concentrar equipos remotos en un rack · rediseñar la oferta de laboratorio. **Factibilidad.** 🔴. Requiere la atribución de sesión a reserva (habilitador 5). **Es el dashboard que sustenta la mejor historia comercial del producto**: «puedo darte el mismo servicio con menos metros cuadrados». ## RM-07 · Ahorro y sostenibilidad 🔴 **Objetivo.** Traducir el uso remoto a dinero y a huella ambiental. Es material de rectoría y de informe de sostenibilidad. **Usuarios.** Rector, Vicerrector Administrativo, Sostenibilidad, Comunicaciones. **KPIs.** **Desplazamientos evitados** (sesiones desde fuera del campus) · km y CO₂ evitados · **horas-puesto físico liberadas y su valor** · energía evitada por apagado programado 🔴 · coste por hora de servicio remoto vs. presencial · **ROI acumulado del módulo remoto**. **Gráficas.** Tarjetas de impacto acumulado · serie de CO₂ evitado por mes · comparación de coste por hora entre modalidades · barras de ahorro por laboratorio. **Filtros.** Periodo, Sede, Laboratorio, Escenario de supuestos. **Drill-down.** Ahorro → sesiones que lo generan → equipos. **Alertas.** Ninguna. Es un dashboard narrativo. **Acciones.** Publicar en el informe de sostenibilidad · justificar la ampliación del módulo. **Factibilidad.** 🔴 **y con una advertencia metodológica que debe ir en la propia pantalla: todos estos números son derivados de supuestos, no medidos.** No hay medidores de energía ni datos de desplazamiento. Lo difícil no es el cálculo, es **acordar y documentar los supuestos** (km medios ida-vuelta, factor de emisión, vatios en reposo por tipo de equipo, coste/hora del puesto físico). Cada tarjeta debe mostrar su supuesto y permitir cambiarlo. **Un número de sostenibilidad sin supuesto visible es una cifra de marketing, y en un comité se desmonta en dos preguntas.** ## RM-08 · Gobierno y seguridad del acceso remoto 🟡 **Objetivo.** Que el acceso remoto sea auditable. Es lo primero que pregunta un oficial de seguridad y hoy no tiene respuesta. **Usuarios.** Oficial de Seguridad, Auditoría Interna, Director TIC. **KPIs.** Sesiones fuera de la ventana horaria autorizada · sesiones de usuarios vencidos o deshabilitados · **cobertura de permisos vs. uso** (entidades con `READ` sobre una conexión frente a usuarios que realmente la usaron: ratio bajo = sobre-aprovisionamiento) · conexiones con permiso concedido a 0 usuarios (huérfanas) · sesiones cortadas por administrador 🔴 · **sesiones huérfanas** (indicador de salud del dato) · % de sesiones con identidad nominal atribuible. **Gráficas.** Tabla de anomalías con severidad · serie de sesiones fuera de ventana · matriz permisos concedidos vs. usados. **Filtros.** Periodo, Tipo de anomalía, Laboratorio, Usuario. **Drill-down.** Anomalía → sesión → usuario → permisos. **Alertas.** Cualquier sesión de usuario deshabilitado · sesión fuera de ventana · **sesión huérfana con más de 6 h**. **Acciones.** Revocar permisos sobre-aprovisionados · cerrar sesiones anómalas · sanear cuentas. **Factibilidad.** 🟡 sobre el esquema estándar de Guacamole, con dos huecos que hay que decir: **las sesiones cortadas por administrador sólo dejan rastro en un archivo de log** (`storage/logs/guac_audit.log`), no en BD, así que no son graficables; y **mientras todos naveguen con `guacadmin`, el % de sesiones con identidad nominal atribuible es 0 %** — que, dicho así, es en sí mismo el KPI de gobierno más importante del módulo. --- # BLOQUE C — Dashboards potenciados con IA **Principio rector, y es una recomendación firme de consultoría:** en esta plataforma **la IA no debe usarse para calcular, sino para explicar, priorizar y redactar.** El cálculo debe ser SQL determinista y auditable. La razón es práctica: un comité universitario acepta un número que puede reproducir en una hoja de cálculo; no acepta un número que salió de un modelo que nadie puede inspeccionar. Y hay una razón técnica: no existe ninguna tubería de ML en el proyecto, mientras que **sí existe inferencia LLM operativa con dos proveedores y *tool calling***. ## IA-01 · Predicción de demanda 🔴 **Objetivo.** Prever solicitudes por espacio, día y franja a 14 días. **Método recomendado (v1, sin ML).** Media móvil de las últimas 4 semanas del mismo día y franja × índice de estacionalidad del periodo académico, corregida por festivos y bloqueos. Materializado por job nocturno en `predicciones_demanda`. **KPIs.** Demanda prevista con intervalo · **MAPE del modelo por espacio** · sesgo (¿sobre o subestima?) · franjas con déficit previsto. **Gráficas.** Histórico + predicción con banda · heatmap de déficit previsto · curva de calibración. **Alertas.** Déficit previsto >20 % en una franja. **Acciones.** Abrir capacidad; desplazar demanda. **Factibilidad.** Precondición dura: **dos semestres de datos limpios**. Hoy no existen. ## IA-02 · Predicción de ocupación 🔴 Igual que IA-01 pero expresado como % de la capacidad ofertada, lo que exige el habilitador 4. **Añade valor sobre IA-01 sólo cuando existe el denominador**; antes de eso son la misma métrica con distinta etiqueta, y presentarlas como dos cosas distintas sería inflar el alcance. ## IA-03 · Recomendación de apertura de laboratorios 🔴 **Objetivo.** Responder «¿qué laboratorio abro el sábado y cuál cierro el viernes por la tarde?». **Método.** Regla sobre agregados: demanda prevista × capacidad disponible × coste de operación (horas-monitor) → recomendación con impacto estimado. **El LLM redacta la justificación en lenguaje natural.** **Salida.** Lista de recomendaciones de apertura/cierre por laboratorio y franja, con ahorro u oportunidad estimada. **Alertas.** Recomendación de alto impacto no atendida en 7 días. **Factibilidad.** Requiere IA-01 y el coste de operación por hora como parámetro, que hoy no existe en ninguna tabla. ## IA-04 · Redistribución de equipos 🔴 **Objetivo.** Balancear el parque. **Es la recomendación con evidencia más contundente de toda la auditoría**: en producción, 10 equipos de 764 absorbieron el 80 % de los préstamos porque se entregaba siempre el mismo portátil hasta que moría. **Método.** Índice de uso por equipo vs. media del laboratorio → propuesta de movimientos concretos («mover PC-27 de Lab A a Lab C») con el impacto esperado en el equilibrio (reducción del Gini). **KPIs.** Gini del parque antes y después · equipos sobre y subutilizados · movimientos propuestos y aceptados. **Gráficas.** Curva de Lorenz antes/después · matriz origen→destino de movimientos propuestos. **Alertas.** Gini por encima del umbral institucional. **Factibilidad.** 🔴 por el habilitador 5 (inventario unificado), pero **la lógica es aritmética simple, no IA**. La primera versión útil es una consulta y una tabla. ## IA-05 · Detección de comportamientos anómalos 🟡 **Objetivo.** Encontrar lo que nadie está buscando. **Método.** Reglas estadísticas (z-score sobre la media móvil, no ML) sobre seis señales: reservas fuera del patrón del cliente · ráfagas de reservas y cancelaciones · uso en franjas inusuales · un cliente concentrando un recurso escaso · sesiones remotas fuera de la ventana · operador con volumen de cancelaciones administrativas atípico. **Salida.** Bandeja de anomalías con severidad, evidencia y explicación narrada por el LLM. **Alertas.** Cada anomalía de severidad alta, al dueño del dominio. **Acciones.** Investigar · contactar al cliente · revisar permisos. **Factibilidad.** 🟡 **y es el caso de IA más viable a corto plazo**: se calcula sobre lo que ya existe, no necesita datos nuevos, y el valor percibido es alto. Riesgo a gestionar: **falsos positivos**. Debe empezar con umbrales conservadores y con la posibilidad de que el usuario marque «no es anomalía» para calibrar. ## IA-06 · Detección de equipos y espacios subutilizados 🟡 **Objetivo.** Recuperar capital ocioso, con la advertencia de que «poco usado» no es lo mismo que «inútil». **Método.** Clasificación por reglas en cuatro causas probables: no publicado · sin permisos · averiado (cruce con disponibilidad) · demanda genuinamente baja. **Distinguir la causa es todo el valor**: un equipo sin uso porque no está publicado se arregla en un minuto; uno sin demanda se da de baja. **KPIs.** Recursos subutilizados por causa · valor inmovilizado por causa · recursos recuperados tras la intervención. **Gráficas.** Barras por causa · tabla accionable con la corrección sugerida. **Alertas.** Recurso subutilizado por causa corregible (publicación o permisos) — es una victoria gratuita. **Factibilidad.** 🟡. La parte de conteo es 🟢 hoy; la clasificación por causa requiere el sondeo de disponibilidad (RM-04) para descartar avería. ## IA-07 · Alertas inteligentes 🟡 **Objetivo.** Pasar del dashboard que hay que abrir a la alerta que llega — con criterio, no por volumen. **Diseño del motor.** Tabla `reglas_alerta (Nombre, Dominio, Condicion, Umbral, Ventana, DestinatarioRol, Canal, FrecuenciaMaxima, Activa)` + evaluación en el job nocturno + los dos canales existentes (`alertas` in-app con fan-out por rol y `alertas_email` con worker). **Reglas iniciales de alto valor:** equipo inalcanzable con reserva en la próxima hora · préstamo vencido sin devolver (hoy sólo genera un warning en un log que nadie lee) · cliente a un no-show del bloqueo (**aviso preventivo: hoy el sistema sanciona sin haber avisado**) · franja saturada con lista de espera recurrente · solicitud pendiente a menos de 24 h de su franja · cola de correo estancada · pico de cancelaciones en un espacio · caída de la integración con Guacamole. **KPIs del propio motor.** Alertas emitidas · **tasa de acción** (¿alguien hizo algo?) · tasa de descarte · tiempo medio hasta la acción · **fatiga** (alertas por destinatario y día). **Factibilidad.** 🟡. Existen los dos canales, el worker, los umbrales ya parametrizados por entorno y un servicio que ya detecta las anomalías clave. **Faltan tres cosas y son las que definen si funciona: el motor de reglas, la deduplicación anti-fatiga** (nada impide hoy enviar la misma alerta 288 veces al día) **y el registro de si la alerta produjo una acción.** Una alerta que nadie atiende es peor que no tenerla: entrena al equipo a ignorar el sistema. ## IA-08 · Asistente analítico conversacional 🟢 **Objetivo.** Que un decano pregunte «¿cuántas horas usó Ingeniería el semestre pasado y cómo va contra el anterior?» y obtenga la cifra, el gráfico y la explicación. **Método.** Ampliar el asistente existente con **herramientas de solo lectura** que envuelvan los agregados ya construidos: `getKpis`, `getKpisPrevious`, `getOcupacionHeatmap`, `getFunnelReservas`, `getTopEspacios`, `getNoShowPorFranja`, y una tool `generar_reporte_catalogo(codigo, desde, hasta, filtros)` que dispare los 16 reportes formales. **KPIs del asistente.** Consultas por usuario · tools más invocadas · tokens y coste · **tasa de confirmación de acciones propuestas** (la métrica directa de confianza en la IA) · % de preguntas resueltas sin escalar. **Factibilidad.** 🟢 **y es la extensión de mayor efecto percibido con menor riesgo de todo el bloque C.** El loop agéntico, el patrón de tool parametrizada, `generar_grafica` con ApexCharts y el registro de tokens ya funcionan end-to-end. Son ~6 tools nuevas, todas de lectura, sin un solo `UPDATE`. Y hay tres huecos actuales que conviene cerrar en el mismo trabajo: el asistente es **ciego a activos, lista de espera, bloqueos, tickets y al historial de Guacamole**, **no puede invocar los 16 reportes del catálogo**, y **no se puede ejecutar fuera de una petición web** — lo que hoy impide el resumen operativo diario por correo. --- ## 4.99 Resumen de factibilidad de los 46 dashboards | Bloque | 🟢 hoy | 🟡 con transformación | 🔴 requiere habilitador | |---|---|---|---| | A — Los 30 solicitados | 2 (DB-07, DB-17) | 13 | 15 | | B — Escritorio remoto (8) | 0 | 4 | 4 | | C — Con IA (8) | 1 (IA-08) | 3 | 4 | | **Total (46 fichas)** | **3** | **20** | **23** | **Lectura ejecutiva.** Sólo 3 de los 46 dashboards se pueden construir hoy tal como se pidieron. **Pero eso no significa que falten dos años de trabajo**: los cinco habilitadores de la Parte 7 mueven a verde o amarillo **19 de los 23 rojos**. El cuello de botella no es el número de dashboards: es un puñado pequeño de piezas de datos que faltan, y tres de ellas se resuelven en días. --- *Continúa en la [Parte 5 — Oportunidades](05_OPORTUNIDADES.md).*