Migrazione
Cambiare sistema di programmazione: che cosa deve davvero essere trasferito
I dati sono la metà facile. Ciò che si rompe è ciò che sta fuori dal software — i link salvati nei preferiti, il feed da cui dipende un altro dipartimento e le abitudini di chi era già fluente nel vecchio sistema.
Se state lasciando un sistema specifico
Questo articolo riguarda la decisione in sé, qualunque sistema stiate usando. Esiste anche una pagina per ciascun sistema in uso, scritta nel vocabolario di quel sistema e onesta su ciò che non facciamo: Scientia Syllabus Plus, Untis, CELCAT e TimeEdit.
Iniziate separando quattro cose diverse
Di solito se ne parla come di un unico progetto. Non hanno quasi nulla in comune.
La struttura — programmi, anni, percorsi di studio, moduli, gruppi e la gerarchia che li unisce. È lo scheletro, è la parte che con più probabilità esiste già nel Vostro sistema informativo degli studenti, ed è la parte da trasferire da lì anziché dal vecchio sistema di programmazione.
Le risorse — aule con capienze e attrezzature reali, edifici, personale con i propri dipartimenti. L'ufficio tecnico e le risorse umane di solito detengono dati migliori di entrambi i sistemi di programmazione, e una migrazione è un'occasione rara per correggerli mentre qualcuno presta attenzione.
L'orario di quest'anno — le lezioni effettivamente collocate. Vale la pena importarlo, ed è rapido da importare, ma è il meno prezioso dei quattro: quello dell'anno prossimo viene generato, non copiato.
Tutto ciò che punta al vecchio sistema — i link, i feed, gli schermi, le integrazioni. È la metà che viene dimenticata nel piano e ricordata nella prima settimana.
Che cosa si trasferisce bene
- Tutto ciò che è un elenco. Aule, personale, moduli, programmi, gruppi. Quasi ogni sistema li esporta e, dove non lo fa, di solito può farlo il database sottostante.
- I vincoli, una volta riclassificati. Raramente si trasferiscono alla lettera, ed è un vantaggio: la migrazione è il momento di distinguere le regole che devono valere dalle preferenze che si vorrebbero, cosa che la maggior parte degli atenei non ha mai fatto. La distinzione, con esempi.
- L'orario attuale, come punto di partenza per il primo periodo mentre le persone prendono confidenza.
- Le disponibilità, se le avete per iscritto. La disponibilità del personale raccolta negli anni è un vero patrimonio di conoscenza dell'ateneo e vale la pena portarla con sé.
Che cosa non si trasferisce, e non deve
La soluzione generata l'anno scorso. Codifica i vincoli dell'anno scorso, le dimensioni delle coorti dell'anno scorso e le aule dell'anno scorso. Rigenerare dalla struttura è più veloce che riconciliare una risposta vecchia di un anno, ed è il primo test onesto per capire se i Vostri vincoli siano mai stati scritti correttamente.
Le soluzioni di ripiego. Ogni orario di lunga data contiene accorgimenti che esistono perché il vecchio software non sapeva fare qualcosa: un modulo diviso in tre perché il sistema non aveva modo di esprimere uno schema quindicinale, un'aula fittizia inventata per sostenere un vincolo. Portarli con sé significa portare una limitazione che state pagando per lasciarvi alle spalle. Trovateli e chiedetevi a che cosa servissero.
Il foglio di calcolo privato di qualcuno. Ce n'è sempre uno, di solito è portante, e la migrazione è il momento in cui deve diventare parte del sistema o essere dismesso deliberatamente.
La parte che si rompe fuori dal software
Nulla di tutto ciò è un problema di dati, e tutto è il lunedì mattina di qualcuno.
- Link salvati nei preferiti. Studenti e personale hanno salvato un URL del proprio orario, talvolta anni fa. Se il nuovo si trova altrove, decidete che cosa debba fare il vecchio indirizzo — reindirizzare, o lasciare una pagina che spieghi dove andare. Non fare né l'una né l'altra cosa è la ferita autoinflitta più comune in una migrazione.
- Abbonamenti al calendario. Chiunque abbia abbonato il proprio telefono al proprio orario ha un feed che smetterà silenziosamente di aggiornarsi anziché fallire in modo visibile. Se ne accorgerà solo quando perderà qualcosa.
- Schermi e segnaletica. I display dell'atrio sono di solito configurati una volta, da qualcuno che nel frattempo se n'è andato, e puntano a un URL che nessuno guarda da tre anni.
- Feed verso altri sistemi. L'ambiente di apprendimento virtuale, il sistema delle presenze, il chiosco di prenotazione delle aule, il report che qualcuno dell'amministrazione esegue ogni trimestre. Chiedete a ogni dipartimento che cosa prelevi dall'orario, per iscritto, prima del passaggio anziché dopo.
- Le persone che erano fluenti. Due o tre colleghi erano rapidi nel vecchio sistema. Per un periodo saranno più lenti, e saranno quelli a cui si chiederà di risolvere tutto. Pianificatelo anziché esserne sorpresi.
Un ordine che funziona
Censite ciò che punta all'orario
Prima di qualsiasi cosa tecnica. Ogni link, feed, schermo e integrazione, con un nome accanto. Questo elenco è il vero ambito del progetto e non è mai breve come ci si aspetta.
Trasferite la struttura, dal sistema informativo degli studenti ove possibile
Programmi, anni, percorsi, moduli, gruppi. Se il Vostro sistema informativo degli studenti li contiene, importateli da lì anziché dal vecchio sistema di programmazione, e avrete fissato nel contempo la fonte di verità.
Trasferite le risorse, e correggetele
Aule e capienze dall'ufficio tecnico, personale dalle risorse umane. Aspettatevi di trovare aule che non esistono più e capienze cambiate insieme all'arredo.
Importate l'orario attuale e pubblicatelo in sola lettura
Dà a tutti qualcosa di familiare da guardare, ed è il modo più rapido per scoprire che cosa avete sbagliato: le persone riconoscono il proprio insegnamento.
Ricostruite i vincoli come rigidi e flessibili
Non è un esercizio di traduzione. Ogni regola viene classificata deliberatamente, e quelle che nessuno sa giustificare vengono scartate.
Generate in parallelo, per un periodo, e confrontate
Fate funzionare il nuovo sistema accanto al vecchio per un solo periodo prima di impegnarVi. Confrontate l'utilizzo delle aule e il carico del personale, non l'impressione.
Cambiate i link per ultimi, e tutti insieme
Reindirizzamenti, feed, schermi e abbonamenti in un solo giorno, dall'inventario del primo passaggio.
Quanto tempo richiede
L'infrastruttura non è il vincolo. Configuriamo l'hosting, importiamo l'orario esistente di un ateneo e mettiamo a posto le sue pagine web in pochi giorni — questa parte è di routine, ed è ciò in cui siamo più bravi di chiunque altro nel nostro mercato.
Il resto sono i Vostri dati e le Vostre integrazioni. Un primo ciclo completo — struttura, risorse, disponibilità, vincoli, generazione, verifica, pubblicazione — richiede in genere alcune settimane, e il fattore che pesa di più è la raccolta delle disponibilità del personale, non qualcosa che faccia il software. Gli anni successivi sono drasticamente più brevi, perché la struttura viene riportata avanti e occorre occuparsi solo delle modifiche.
Il riepilogo onesto: raramente è il software a rendere lunga una migrazione. Chiunque Vi dica il contrario Vi sta vendendo la metà facile.
Domande da porre a chiunque stiate valutando
- Potete importare il nostro orario esistente, e in quale formato Vi serve?
- Che cosa succede ai link che i nostri studenti hanno già salvato?
- La Vostra interfaccia di integrazione è documentata pubblicamente, così che i nostri sviluppatori possano valutarla prima di impegnarci? La nostra lo è.
- Possiamo far funzionare entrambi i sistemi in parallelo per un periodo?
- Come si presenta il secondo anno — quanto di questo lavoro si ripete?
Desiderate vederlo in funzione?
Prenotate una presentazione online di 45 minuti e la illustreremo sul problema di programmazione del Vostro ateneo.