Komplett guide
Så bygger ni ett universitetsschema
Processen, i den ordning den faktiskt sker, med de delar som tar mest tid ärligt markerade. Skriven för registratorer och schemaläggare snarare än för datavetare.
Före allt annat: bestäm vad ett schema innebär
Det första beslutet är strukturellt och nästan alla gör fel på det minst en gång. Ett enda schema bör täcka allt som delar resurser. Om två fakulteter utnyttjar samma rum, samma personal eller samma kurser hör de hemma i ett schema även om de i praktiken schemalägger oberoende.
Att dela upp dem ger två scheman som måste stämmas av för hand varje gång något av dem ändras, vilket är exakt det arbete ni försöker eliminera. Dela bara där gränsen är verklig: inga delade rum, ingen delad personal, separat publicering.
De sex stegen
Bygg strukturen
Program, år, studieområden, kurser och hierarkin som förbinder dem. Detta är skelettet som allt annat hänger på, och att få det fel är dyrt att rätta senare. Importera det från ert studieadministrativa system om ni kan.
Läs in resurserna
Rum med verkliga kapaciteter och utrustning, byggnader med verkliga restider mellan dem, lärare med sina institutioner och undervisningsbörda. Fastighets- och personalavdelningar har ofta bättre data än schemaläggningsenheten.
Samla in tillgänglighet
Det steg som äter upp kalendern. Gör det inte via e-post. Öppna ett webbokningssystem för er undervisande personal och låt dem skriva in sina egna lediga timmar, och påminn sedan dem som inte svarat med en automatisk påminnelse i stället för hundra telefonsamtal.
Definiera villkor
Skilj de regler som aldrig får brytas från de önskemål ni gärna vill få uppfyllda. Att behandla varje önskemål som absolut är den i särklass vanligaste orsaken till att ett schema visar sig vara olösbart.
Generera, och argumentera sedan med det
Lås allt som verkligen inte kan flyttas, generera och titta på vad som kom ut. Ta fram två eller tre varianter med olika prioriteringar och jämför dem på utnyttjande- och arbetsbördesuppgifter i stället för på intryck.
Kontrollera, och publicera sedan
Låt lärare kontrollera sina egna scheman före publicering — det är långt billigare att rätta en invändning nu än i vecka ett. Publicera sedan till alla kanaler på en gång från en enda källa.
Var tiden faktiskt går åt
Inte där de flesta lärosäten väntar sig.
Be en schemaläggningsenhet uppskatta arbetsinsatsen och de beskriver oftast generering och konfliktlösning som den svåra delen. Mät det och svaret är nästan alltid insamling av tillgänglighet: två till tre veckors jagande, följt av manuell datainmatning, följt av rättelser som kommer efter att kalkylbladet stängts.
Därför förändrar tillgänglighet via självbetjäning kalkylen mer än någon algoritmisk förbättring kan göra. Om genereringen redan tar under en minut sparar man ingenting på att göra den snabbare. Att ta bort en insamlingsfas på tre veckor sparar tre veckor.
Den näst största tidstjuven är integrationen med system som inte var konstruerade för att tala med varandra. Budgetera uttryckligen för den, och ta tidigt reda på vilka av era system som har användbara API:er.
Vanliga misstag
- Att behandla önskemål som hårda villkor. Om allt är oantastligt går ingenting att lösa, och ni kommer att tillbringa de närmaste två veckorna med att åsidosätta era egna regler.
- Att samla in tillgänglighet via e-post. Det skalar inte bortom ungefär fyrtio anställda, och uppgifterna är föråldrade innan de hunnit registreras.
- Att dela upp ett schema i flera. Varje delad resurs blir en manuell avstämning som ni får göra varje vecka.
- Att publicera innan lärarna har kontrollerat. Invändningar som kommer efter publiceringen kostar långt mer än invändningar som kommer före den.
- Att publicera en PDF. Studenterna tar en skärmdump av den i september och tittar fortfarande på den i mars, tre salsbyten senare.
- Att aldrig mäta beläggningen. Ni schemalägger lärosätets två dyraste resurser och tar inte fram några data om hur väl det går.
En realistisk tidsplan
Vid en första implementering kan molninfrastrukturen vara igång på en dag och utbildningen tar tre till fem dagar. Hela cykeln — struktur, resurser, tillgänglighet, villkor, generering, verifiering, publicering — tar vanligtvis några veckor och styrs av era data och era integrationer snarare än av programvaran.
Under följande år går det dramatiskt snabbare, eftersom förra årets struktur förs vidare och bara ändringarna behöver uppmärksamhet.
Vill ni se hur det fungerar?
Boka en onlinepresentation på 45 minuter, så går vi igenom den mot ert eget lärosätes schemaläggningsproblem.