Migrering
Att byta schemaläggningssystem: vad som faktiskt måste flyttas
Data är den enkla hälften. Det som går sönder är det som ligger utanför programvaran — de länkar folk bokmärkt, flödet som en annan institution är beroende av och vanorna hos alla som redan var flytande i det gamla systemet.
Om ni lämnar ett namngivet system
Den här artikeln handlar om själva beslutet, vilket system ni än använder. Det finns också en sida per etablerat system, skriven med det systemets eget språkbruk och ärlig om vad vi inte gör: Scientia Syllabus Plus, Untis, CELCAT och TimeEdit.
Börja med att skilja på fyra olika saker
De diskuteras oftast som ett projekt. De har nästan ingenting gemensamt.
Strukturen — program, år, studieinriktningar, kurser, grupper och hierarkin som förbinder dem. Det är skelettet, det är den del som mest sannolikt redan finns i ert studieadministrativa system, och det är den del som är värd att flytta därifrån snarare än från det gamla schemaläggningssystemet.
Resurserna — salar med verkliga kapaciteter och utrustning, byggnader, personal med sina institutioner. Fastighetsavdelningen och personalavdelningen har oftast bättre data än något av schemaläggningssystemen, och en migrering är ett sällsynt tillfälle att rätta dem medan någon ägnar det uppmärksamhet.
Det här årets schema — de faktiska placerade lektionerna. Värt att importera, och snabbt att importera, men det är det minst värdefulla av de fyra: nästa års schema genereras, inte kopieras.
Allt som pekar på det gamla systemet — länkarna, flödena, skärmarna, integrationerna. Det är den hälft som glöms i planen och minns i vecka ett.
Vad som överförs väl
- Allt som är en lista. Salar, personal, kurser, program, grupper. Nästan varje system exporterar dessa, och där det inte gör det kan databasen under det oftast göra det.
- Villkor, när de omklassificerats. De överförs sällan bokstavligt, och det är en fördel: migreringen är tillfället att sortera de regler som måste gälla från de önskemål ni skulle vilja ha, vilket de flesta lärosäten aldrig gjort. Skillnaden, med exempel.
- Det nuvarande schemat, som utgångspunkt för första terminen medan folk hittar fotfästet.
- Tillgänglighet, om ni har den skriftligt. Personalens tillgänglighet insamlad under år är verklig institutionell kunskap och värd att föra med sig.
Vad som inte gör det, och inte bör
Förra årets genererade lösning. Den kodar förra årets villkor, förra årets kullstorlekar och förra årets salar. Att generera om från strukturen går snabbare än att stämma av ett år gammalt svar, och det är det första ärliga testet av om era villkor någonsin var ordentligt nedskrivna.
Nödlösningar. Varje långlivat schema innehåller arrangemang som finns för att den gamla programvaran inte kunde något: en kurs delad i tre för att systemet saknade sätt att uttrycka ett mönster varannan vecka, en fiktiv sal påhittad för att hålla ett villkor. Att föra dessa vidare är att bära med sig en begränsning som ni betalar för att lämna bakom er. Hitta dem, och fråga vad de var till för.
Någons privata kalkylblad. Det finns alltid ett, det är oftast bärande, och migreringen är tillfället då det måste bli en del av systemet eller medvetet avvecklas.
Det som går sönder utanför programvaran
Inget av detta är ett dataproblem, och allt är någons måndagsmorgon.
- Bokmärkta länkar. Studenter och personal har sparat en URL till sitt eget schema, ibland för flera år sedan. Om det nya ligger någon annanstans, bestäm vad den gamla adressen gör — omdirigera den, eller lämna en sida som förklarar vart man ska gå. Att göra ingetdera är den vanligaste självförvållade skadan i en migrering.
- Kalenderprenumerationer. Den som prenumererat med sin telefon på sitt schema har ett flöde som i det tysta slutar uppdateras i stället för att synligt misslyckas. De märker det inte förrän de missar något.
- Skärmar och skyltar. Skärmar i entréer konfigureras oftast en gång, av någon som sedan har slutat, och pekar på en URL som ingen tittat på på tre år.
- Flöden till andra system. Lärplattformen, närvarosystemet, bokningskiosken för salar, rapporten som någon på ekonomi kör varje kvartal. Fråga varje institution vad de hämtar från schemat, skriftligt, före bytet i stället för efter.
- De som var flytande. Två eller tre kollegor var snabba i det gamla systemet. Under en termin blir de långsammare, och de blir de som ombeds lösa allt. Planera för det i stället för att överraskas av det.
En ordning som fungerar
Inventera vad som pekar på schemat
Före allt tekniskt. Varje länk, flöde, skärm och integration, med ett namn vid sig. Den här listan är projektets faktiska omfattning och den är aldrig så kort som väntat.
Flytta strukturen, från studieadministrativa systemet där det är möjligt
Program, år, inriktningar, kurser, grupper. Om ert studieadministrativa system har det, importera därifrån i stället för från det gamla schemaläggningssystemet, så har ni samtidigt fastställt sanningskällan.
Flytta resurserna, och rätta dem
Salar och kapaciteter från fastighetsavdelningen, personal från personalavdelningen. Räkna med att hitta salar som inte längre finns och kapaciteter som ändrades när möblerna gjorde det.
Importera det nuvarande schemat och publicera det skrivskyddat
Det ger alla något bekant att titta på, och det är det snabbaste sättet att ta reda på vad ni gjort fel: människor känner igen sin egen undervisning.
Bygg om villkoren som hårda och mjuka
Inte en översättningsövning. Varje regel klassificeras medvetet, och de som ingen kan motivera stryks.
Generera parallellt, under en termin, och jämför
Kör det nya systemet vid sidan av det gamla under en enda termin innan ni binder er. Jämför på salsbeläggning och personalbelastning, inte på intryck.
Byt länkarna sist, och alla på en gång
Omdirigeringar, flöden, skärmar och prenumerationer på en dag, utifrån inventeringen i steg ett.
Hur lång tid det tar
Infrastrukturen är inte begränsningen. Vi sätter upp hosting, importerar ett lärosätes befintliga schema och lägger på plats dess webbsidor på några dagar — den delen är rutin, och det är där vi är bättre än någon annan på vår marknad.
Resten är era data och era integrationer. En första fullständig cykel — struktur, resurser, tillgänglighet, villkor, generering, verifiering, publicering — tar vanligtvis några veckor, och den enskilt största tidstjuven är insamlingen av personalens tillgänglighet snarare än något programvaran gör. Följande år går dramatiskt snabbare, eftersom strukturen förs vidare och bara ändringarna behöver uppmärksamhet.
Den ärliga sammanfattningen: programvaran är sällan det som gör en migrering lång. Den som säger något annat säljer er den enkla hälften.
Frågor värda att ställa till vem ni än utvärderar
- Kan ni importera vårt befintliga schema, och i vilket format behöver ni det?
- Vad händer med de länkar våra studenter redan sparat?
- Är ert integrationsgränssnitt offentligt dokumenterat, så att våra utvecklare kan bedöma det innan vi binder oss? Vårt är det.
- Kan vi köra båda systemen parallellt under en termin?
- Hur ser år två ut — hur mycket av det här arbetet upprepas?
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.