Migración
Cambiar de sistema de horarios: qué debe trasladarse realmente
Los datos son la mitad fácil. Lo que se rompe es lo que está fuera del software — los enlaces que la gente guardó en favoritos, el feed del que depende otro departamento y los hábitos de todos los que ya dominaban el sistema anterior.
Si deja un sistema concreto
Este artículo trata de la decisión en sí, sea cual sea el sistema que use. También hay una página por cada sistema actual, escrita con el vocabulario propio de ese sistema y honesta sobre lo que no hacemos: Scientia Syllabus Plus, Untis, CELCAT y TimeEdit.
Empiece separando cuatro cosas distintas
Suelen discutirse como un solo proyecto. No tienen casi nada en común.
La estructura — programas, cursos, itinerarios de estudio, módulos, grupos y la jerarquía que los une. Es el esqueleto, es la parte con más probabilidad de existir ya en su sistema de información estudiantil, y es la parte que conviene traer de allí y no del antiguo sistema de horarios.
Los recursos — aulas con capacidades y equipamiento reales, edificios, personal con sus departamentos. Las áreas de infraestructura y de recursos humanos suelen tener mejores datos que cualquiera de los dos sistemas de horarios, y una migración es una oportunidad poco frecuente para corregirlos mientras alguien presta atención.
El horario de este año — las lecciones realmente colocadas. Vale la pena importarlo, y se importa rápido, pero es lo menos valioso de los cuatro: el del año próximo se genera, no se copia.
Todo lo que apunta al sistema antiguo — los enlaces, los feeds, las pantallas, las integraciones. Es la mitad que se olvida en el plan y se recuerda en la primera semana.
Lo que se traslada bien
- Todo lo que es una lista. Aulas, personal, módulos, programas, grupos. Casi todos los sistemas los exportan, y donde no lo hacen, la base de datos subyacente suele poder.
- Las restricciones, una vez reclasificadas. Rara vez se trasladan literalmente, y eso es una ventaja: la migración es el momento de separar las reglas que deben cumplirse de las preferencias que le gustaría tener, algo que la mayoría de las instituciones nunca ha hecho. La distinción, con ejemplos.
- El horario actual, como punto de partida del primer trimestre mientras la gente se orienta.
- La disponibilidad, si la tiene por escrito. La disponibilidad del personal recogida durante años es conocimiento institucional real y vale la pena conservarla.
Lo que no se traslada, y no debería
La solución generada el año pasado. Codifica las restricciones del año pasado, los tamaños de cohorte del año pasado y las aulas del año pasado. Regenerar desde la estructura es más rápido que conciliar una respuesta de hace un año, y es la primera prueba honesta de si sus restricciones llegaron a estar bien escritas.
Los parches. Todo horario longevo contiene arreglos que existen porque el software antiguo no podía hacer algo: un módulo dividido en tres porque el sistema no tenía forma de expresar un patrón quincenal, un aula ficticia inventada para sostener una restricción. Trasladarlos es llevarse una limitación que está pagando por dejar atrás. Encuéntrelos y pregunte para qué servían.
La hoja de cálculo privada de alguien. Siempre hay una, suele ser un pilar, y la migración es el momento en que tiene que pasar a formar parte del sistema o retirarse deliberadamente.
La parte que se rompe fuera del software
Nada de esto es un problema de datos, y todo es la mañana del lunes de alguien.
- Enlaces guardados en favoritos. Estudiantes y personal han guardado la URL de su propio horario, a veces hace años. Si el nuevo está en otro lugar, decida qué hace la dirección antigua — redirigirla o dejar una página que explique adónde ir. No hacer ninguna de las dos cosas es la herida autoinfligida más común en una migración.
- Suscripciones de calendario. Cualquiera que haya suscrito su teléfono a su horario tiene un feed que dejará de actualizarse en silencio en lugar de fallar visiblemente. No lo notará hasta que se pierda algo.
- Pantallas y señalización. Las pantallas de los vestíbulos suelen configurarse una vez, por alguien que ya se fue, y apuntan a una URL que nadie ha mirado en tres años.
- Feeds hacia otros sistemas. El entorno virtual de aprendizaje, el sistema de asistencia, el quiosco de reserva de aulas, el informe que alguien de Finanzas ejecuta cada trimestre. Pregunte a cada departamento qué toma del horario, por escrito, antes del cambio y no después.
- Las personas que dominaban el sistema. Dos o tres colegas eran rápidos en el sistema antiguo. Durante un trimestre serán más lentos, y serán a quienes se pida resolver todo. Planifique eso en lugar de sorprenderse.
Un orden que funciona
Haga un inventario de lo que apunta al horario
Antes de cualquier cosa técnica. Cada enlace, feed, pantalla e integración, con un nombre al lado. Esta lista es el alcance real del proyecto y nunca es tan corta como se espera.
Traslade la estructura, desde el SIS cuando sea posible
Programas, cursos, itinerarios, módulos, grupos. Si su sistema de información estudiantil lo contiene, impórtelo de allí y no del antiguo sistema de horarios, y habrá fijado a la vez la fuente de verdad.
Traslade los recursos, y corríjalos
Aulas y capacidades desde Infraestructura, personal desde Recursos Humanos. Espere encontrar aulas que ya no existen y capacidades que cambiaron cuando cambió el mobiliario.
Importe el horario actual y publíquelo en solo lectura
Da a todos algo familiar que mirar, y es la forma más rápida de descubrir qué hizo mal: la gente reconoce su propia docencia.
Reconstruya las restricciones como duras y blandas
No es un ejercicio de traducción. Cada regla se clasifica deliberadamente, y las que nadie puede justificar se descartan.
Genere en paralelo, durante un trimestre, y compare
Ejecute el sistema nuevo junto al antiguo durante un solo trimestre antes de comprometerse. Compare por utilización de aulas y carga del personal, no por impresión.
Cambie los enlaces al final, y todos a la vez
Redirecciones, feeds, pantallas y suscripciones en un día, a partir del inventario del primer paso.
Cuánto tarda
La infraestructura no es la restricción. Configuramos el alojamiento, importamos el horario existente de una institución y ponemos sus páginas web en unos pocos días — esa parte es rutina, y es en lo que somos mejores que nadie en nuestro mercado.
El resto son sus datos y sus integraciones. Un primer ciclo completo — estructura, recursos, disponibilidad, restricciones, generación, verificación, publicación — suele llevar unas semanas, y lo que más consume es recoger la disponibilidad del personal y no algo que haga el software. Los años siguientes son drásticamente más cortos, porque la estructura se traslada y solo hay que atender los cambios.
El resumen honesto: el software rara vez es lo que alarga una migración. Quien le diga lo contrario le está vendiendo la mitad fácil.
Preguntas que conviene hacer a quienquiera que esté evaluando
- ¿Pueden importar nuestro horario existente y en qué formato lo necesitan?
- ¿Qué pasa con los enlaces que nuestros estudiantes ya han guardado?
- ¿Su interfaz de integración está documentada públicamente, para que nuestros desarrolladores puedan juzgarla antes de comprometernos? La nuestra lo está.
- ¿Podemos ejecutar ambos sistemas en paralelo durante un trimestre?
- ¿Cómo es el segundo año — cuánto de este trabajo se repite?
¿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.