Guía completa
Cómo construir un horario universitario
El proceso, en el orden en que realmente ocurre, señalando con honestidad las partes que más tiempo consumen. Escrito para secretarios académicos y responsables de horarios y no para informáticos.
Antes que nada: decida qué significa un horario
La primera decisión es estructural y casi todos se equivocan en ella al menos una vez. Un único horario debe cubrir todo lo que comparte recursos. Si dos facultades usan las mismas aulas, el mismo personal o los mismos módulos, pertenecen a un solo horario aunque en la práctica programen de forma independiente.
Separarlas produce dos horarios que hay que conciliar a mano cada vez que cambia uno de ellos, que es exactamente el trabajo que se quiere eliminar. Separe solo donde la frontera sea real: sin aulas compartidas, sin personal compartido, publicación independiente.
Las seis etapas
Construir la estructura
Programas, años, áreas de estudio, módulos y la jerarquía que los conecta. Es el esqueleto del que cuelga todo lo demás, y equivocarse aquí es caro de corregir más tarde. Impórtela desde su sistema de información estudiantil si puede.
Cargar los recursos
Aulas con capacidades y equipamiento reales, edificios con tiempos de traslado reales entre ellos, docentes con sus departamentos y cargas de docencia. Infraestructura y RR. HH. suelen tener mejores datos que la oficina de horarios.
Recopilar la disponibilidad
La etapa que devora el calendario. No la haga por correo. Abra un sistema web de reservas a su personal docente y deje que cada uno introduzca sus propias horas libres, y luego insista a quienes no respondan con un único recordatorio automático en lugar de cien llamadas telefónicas.
Definir las restricciones
Separe las reglas que nunca deben romperse de las preferencias que le gustaría satisfacer. Tratar toda preferencia como absoluta es la razón más común de que un horario resulte irresoluble.
Generar y luego discutirlo
Bloquee lo que realmente no puede moverse, genere y mire lo que salió. Produzca dos o tres variantes con prioridades distintas y compárelas por las cifras de utilización y de carga de trabajo, no por impresión.
Verificar y luego publicar
Deje que los docentes revisen sus propios horarios antes de la publicación — es mucho más barato atender una objeción ahora que en la primera semana. Luego publique en todos los canales a la vez desde una única fuente.
Dónde se va realmente el tiempo
No donde la mayoría de las instituciones esperan.
Pida a una oficina de horarios que estime el esfuerzo y normalmente describirá la generación y la resolución de conflictos como lo difícil. Mídalo y la respuesta casi siempre es la recopilación de disponibilidad: dos o tres semanas de insistencia, seguidas de introducción manual de datos, seguidas de correcciones que llegan después de que se cerró la hoja de cálculo.
Por eso la disponibilidad de autoservicio cambia la aritmética más que cualquier mejora algorítmica. Si la generación ya tarda menos de un minuto, hacerla más rápida no ahorra nada. Eliminar una fase de recopilación de tres semanas ahorra tres semanas.
El segundo mayor consumidor es la integración con sistemas que no fueron diseñados para hablar entre sí. Presupuéstela de forma explícita y averigüe pronto cuáles de sus sistemas tienen API utilizables.
Errores comunes
- Tratar las preferencias como restricciones duras. Si todo es inviolable, nada tiene solución, y pasará la quincena siguiente anulando sus propias reglas.
- Recopilar la disponibilidad por correo. No escala más allá de unas cuarenta personas, y los datos ya están desactualizados antes de introducirse.
- Dividir un horario en varios. Cualquier recurso compartido se convierte en una conciliación manual que hará cada semana.
- Publicar antes de que los docentes verifiquen. Las objeciones que llegan tras la publicación cuestan mucho más que las que llegan antes.
- Publicar un PDF. Los estudiantes le sacan una captura en septiembre y siguen mirándola en marzo, tres cambios de aula después.
- No medir nunca la utilización. Está programando los dos recursos más caros de su institución y no produce ningún dato sobre lo bien que lo hace.
Un calendario realista
En una primera implementación, la infraestructura en la nube puede estar funcionando en un día y la formación lleva de tres a cinco días. El ciclo completo — estructura, recursos, disponibilidad, restricciones, generación, verificación, publicación — suele durar unas pocas semanas, dominadas por sus datos y sus integraciones más que por el software.
En los años siguientes es drásticamente más corto, porque la estructura del año pasado se arrastra y solo hay que atender los cambios.
¿Quiere verlo funcionando?
Reserve una presentación en línea de 45 minutos y la recorreremos con el propio problema de programación de su institución.