El punto de partida: ¿cómo se montaba el horario?
El centro de formación trabaja con el ciclo habitual del sector: los grupos del mes siguiente deben quedar formados antes del día 15 del mes en curso. Las fichas de cursos, grupos y subgrupos ya estaban en el CRM como smart-processes, con duración, tipo de curso, límites de participantes y vínculos con las operaciones de los alumnos matriculados. Datos había de sobra. Faltaba la herramienta que convirtiera esos datos en un calendario.
Así que lo montaba de cabeza y sobre papel. Las reglas que hay que sostener a la vez son unas cuantas: jornada de ocho horas, sin fines de semana, dos grupos del mismo curso no pueden ocupar las mismas horas (salvo en cursos donde los grupos paralelos están permitidos explícitamente), en los cursos mixtos los grupos cortos y largos deben alternarse de forma equilibrada, el último grupo del mes puede terminar ya en el siguiente y la numeración vuelve a empezar cada año.
Aquí el coste del error llega tarde. Un solape entre dos grupos no se señala en el momento en que se comete: simplemente se hace visible cuando los alumnos ya han llegado a clase. Y lo resuelven las personas, no el sistema.
¿Por qué escribir un módulo y no seguir configurando el CRM?
Un CRM estándar hace bien aquello para lo que está hecho: fichas, listas, kanban, permisos, procesos de negocio. Lo que no sabe hacer es repartir horas entre días laborables según las reglas propias de un centro de formación concreto, y ninguna configuración de campos lo va a resolver. Aquí hace falta código, no un configurador.
La restricción clave nos la pusimos nosotros: ni un cambio en el núcleo de la plataforma. Todo el módulo vive en su propio directorio aislado y usa solo mecanismos soportados: tablas propias, controladores, extensiones de interfaz y la API de smart-processes. Es un requisito de apariencia aburrida del que depende todo lo demás: el módulo está aislado del núcleo, así que se puede mantener aparte y llevárselo con los datos si el cliente alguna vez migra a otra plataforma.
¿Qué construimos?
En el menú principal del CRM apareció la entrada «Horario de grupos», con dos pantallas principales: el calendario y el borrador.
El calendario muestra una cuadrícula de días laborables con chips de grupo: nombre del curso, tipo (largo o corto), número de grupo y número de alumnos. Si en un día caen más de dos grupos, el resto se pliega en un distintivo «+N». Los grupos que empezaron el mes anterior y continúan llevan un marcador de continuación. Los grupos que, tras ediciones manuales, empiezan a solaparse contra las reglas se resaltan en rojo al momento, no a posteriori.
- Filtros: periodo (mes, semana, rango libre), cursos con selección múltiple, tipo de curso y estado de los certificados: emitidos o no.
- Impresión del horario del periodo actual respetando los filtros aplicados, maquetada para A4.
- Al pulsar un curso o el número de un grupo se abre su ficha en un panel lateral, sin salir de la página.
- Tres roles: el inspector consulta e imprime, la metodóloga genera y configura, y el administrador puede además regenerar un horario ya finalizado.
La segunda pantalla es el borrador. La metodóloga pulsa «Generar» y el sistema reparte los grupos del mes siguiente según la configuración de cada curso. Por ahora es un borrador visible y corregible: al arrastrar el micro-bloque de un grupo a otro día se recalculan las fechas de inicio y fin, la ocupación de horas y los conflictos. Cuando el resultado convence, «Generar» por segunda vez. Solo entonces el sistema asigna los números en formato año/correlativo, fija los horarios y crea los elementos reales del smart-process «Grupos».
La configuración es una pantalla aparte donde, para cada curso, se indica cuántos grupos cortos y largos hay al mes, el total y si el curso participa o no en la generación automática. Eso es lo que convierte el módulo de una automatización puntual en una herramienta: las reglas cambian a lo largo del año, aparecen cursos nuevos, y la metodóloga los edita sin contar con nosotros.
¿Qué dos detalles deciden si un módulo así aguanta?
El primero es el planificador por «olas». Los grupos de un mismo curso se reparten en olas: los paralelos ocupan la misma franja horaria y los secuenciales van uno detrás de otro. Una ola llena la jornada de ocho horas; si no cabe, pasa al siguiente día laborable, y si termina a media jornada, el resto del día queda para la ola siguiente. Los fines de semana se saltan. La planificación va en horas y admite valores fraccionarios, algo que hará falta cuando llegue el plan de preparación por lecciones.
El segundo es la finalización en dos fases. La creación de elementos del CRM no se puede envolver en una transacción de base de datos, así que un fallo a medio camino dejaría la mitad de los grupos creados y la otra mitad no. Por eso el módulo crea primero los elementos en el CRM, después actualiza sus propias tablas dentro de una transacción y, si esa segunda fase falla, revierte la primera borrando los grupos recién creados. Pulsar «Generar» dos veces no genera duplicados. Cada acción relevante —generación, arrastre, finalización— queda registrada: quién, qué y cuándo.
¿Cuánto llevó?
La estimación inicial era de 60 horas de desarrollo y 2,5–3 meses de plazo. Una versión funcional estaba en el servidor del cliente a las dos semanas del primer commit; después vinieron la aceptación, los ajustes que plantearon las metodólogas y el cierre final. No lo llamamos «hecho en dos semanas»: escribir el código y poner un sistema en producción son duraciones distintas, y es más honesto mostrar las dos.
- Unas 6500 líneas de código propio entre backend, interfaz y estilos.
- 73 tests unitarios sobre el planificador de olas, el detector de conflictos, la numeración de grupos y el control de permisos.
- Tres tablas propias de base de datos para la configuración, las ejecuciones de generación y los elementos del borrador.
- Cero cambios en el núcleo de la plataforma: el módulo está aislado y se lleva consigo en una migración.
El trabajo no terminó ahí: en cola están los subgrupos con índice alfabético y una pestaña específica para metodólogas con el desglose de horas en teoría, práctica y exámenes. El módulo se diseñó pensando en eso, así que los bloques siguientes se añaden en lugar de reescribir los anteriores.
¿Qué llevarse de aquí?
Cuando una empresa choca con un CRM que «casi encaja», se suelen barajar dos salidas: aguantar o cambiar de sistema. Hay una tercera: escribir la pieza que falta encima de lo que ya se usa. Los datos, los permisos, las fichas de cliente, las operaciones y las costumbres del equipo se quedan donde están; solo se añade lo que faltaba. Auspex desarrolla estas ampliaciones como módulos independientes, precisamente para poder seguir evolucionándolas sin temer a las actualizaciones.