Migração
Mudar de sistema de horários: o que realmente tem de ser transferido
Os dados são a metade fácil. O que falha é o que está fora do software — as ligações que as pessoas guardaram nos favoritos, o feed de que outro departamento depende e os hábitos de todos os que já dominavam o sistema antigo.
Se está a abandonar um sistema concreto
Este artigo trata da decisão em si, seja qual for o sistema que utiliza. Existe também uma página por sistema incumbente, escrita no vocabulário desse sistema e honesta quanto ao que não fazemos: Scientia Syllabus Plus, Untis, CELCAT e TimeEdit.
Comece por separar quatro coisas diferentes
Costumam ser discutidas como um único projeto. Têm quase nada em comum.
A estrutura — programas, anos, percursos de estudo, disciplinas, grupos e a hierarquia que os liga. É o esqueleto, é a parte com maior probabilidade de já existir no seu sistema de informação de estudantes e é a parte que vale a pena transferir a partir daí e não do antigo sistema de horários.
Os recursos — salas com capacidades e equipamento reais, edifícios, docentes com os seus departamentos. Os serviços de instalações e os recursos humanos costumam deter dados melhores do que qualquer dos sistemas de horários, e uma migração é uma oportunidade rara de os corrigir enquanto alguém está atento.
O horário deste ano — as aulas efetivamente colocadas. Vale a pena importá-lo, e é rápido de importar, mas é o menos valioso dos quatro: o do próximo ano é gerado, não copiado.
Tudo o que aponta para o sistema antigo — as ligações, os feeds, os ecrãs, as integrações. É a metade que se esquece no plano e de que se lembra na primeira semana.
O que se transfere bem
- Tudo o que é uma lista. Salas, docentes, disciplinas, programas, grupos. Quase todos os sistemas os exportam e, quando não o fazem, a base de dados subjacente normalmente consegue.
- As restrições, depois de reclassificadas. Raramente se transferem literalmente, e isso é uma vantagem: a migração é o momento de separar as regras que têm de se verificar das preferências que gostaria de ter, algo que a maioria das instituições nunca fez. A distinção, com exemplos.
- O horário atual, como ponto de partida para o primeiro período enquanto as pessoas se adaptam.
- A disponibilidade, se a tiver por escrito. A disponibilidade dos docentes recolhida ao longo de anos é conhecimento institucional real e vale a pena levá-la.
O que não se transfere, e não deve
A solução gerada no ano anterior. Codifica as restrições do ano passado, as dimensões das coortes do ano passado e as salas do ano passado. Regenerar a partir da estrutura é mais rápido do que reconciliar uma resposta com um ano, e é o primeiro teste honesto para saber se as suas restrições alguma vez foram bem escritas.
Soluções de contorno. Todo o horário com longa vida contém arranjos que existem porque o software antigo não conseguia fazer algo: uma disciplina dividida em três porque o sistema não tinha forma de exprimir um padrão quinzenal, uma sala fictícia inventada para sustentar uma restrição. Levá-los consigo é levar uma limitação que está a pagar para deixar para trás. Encontre-os e pergunte para que serviam.
A folha de cálculo privada de alguém. Há sempre uma, costuma ser estrutural, e a migração é o momento em que tem de passar a fazer parte do sistema ou ser deliberadamente abandonada.
A parte que falha fora do software
Nada disto é um problema de dados, e tudo isto é a manhã de segunda-feira de alguém.
- Ligações guardadas nos favoritos. Estudantes e docentes guardaram um URL do seu próprio horário, por vezes há anos. Se o novo estiver noutro local, decida o que faz o endereço antigo — redirecioná-lo ou deixar uma página a explicar para onde ir. Não fazer nenhuma das duas coisas é a ferida autoinfligida mais comum numa migração.
- Subscrições de calendário. Quem subscreveu o telemóvel ao seu horário tem um feed que deixará silenciosamente de se atualizar, em vez de falhar visivelmente. Só repararão quando perderem algo.
- Ecrãs e sinalética. Os ecrãs dos átrios costumam ser configurados uma só vez, por alguém que entretanto saiu, e apontam para um URL que ninguém consulta há três anos.
- Feeds para outros sistemas. O ambiente virtual de aprendizagem, o sistema de assiduidade, o quiosque de reserva de salas, o relatório que alguém das Finanças executa todos os trimestres. Pergunte a cada departamento, por escrito, o que obtém do horário, antes da mudança e não depois.
- As pessoas que dominavam o sistema. Dois ou três colegas eram rápidos no sistema antigo. Durante um período serão mais lentos, e serão eles a quem pedirão que resolva tudo. Planeie isso em vez de ser apanhado de surpresa.
Uma ordem que funciona
Inventariar o que aponta para o horário
Antes de qualquer trabalho técnico. Todas as ligações, feeds, ecrãs e integrações, com um nome associado a cada. Esta lista é o âmbito real do projeto e nunca é tão curta como se espera.
Transferir a estrutura, a partir do SIS sempre que possível
Programas, anos, percursos, disciplinas, grupos. Se o seu sistema de informação de estudantes os contém, importe a partir daí e não do antigo sistema de horários, e fixa ao mesmo tempo a fonte de verdade.
Transferir os recursos e corrigi-los
Salas e capacidades a partir dos serviços de instalações, docentes a partir dos recursos humanos. Conte encontrar salas que já não existem e capacidades que mudaram quando o mobiliário mudou.
Importar o horário atual e publicá-lo apenas para leitura
Dá a todos algo familiar para consultar e é a forma mais rápida de descobrir o que correu mal: as pessoas reconhecem a sua própria lecionação.
Reconstruir as restrições como rígidas e flexíveis
Não é um exercício de tradução. Cada regra é classificada deliberadamente, e as que ninguém consegue justificar são abandonadas.
Gerar em paralelo, durante um período, e comparar
Execute o novo sistema ao lado do antigo durante um único período antes de se comprometer. Compare a utilização das salas e a carga dos docentes, não a impressão.
Mudar as ligações por último e todas de uma vez
Redirecionamentos, feeds, ecrãs e subscrições num único dia, a partir do inventário do primeiro passo.
Quanto tempo demora
A infraestrutura não é a restrição. Configuramos o alojamento, importamos o horário existente de uma instituição e colocamos as suas páginas web em funcionamento em poucos dias — essa parte é rotina, e é nela que somos melhores do que qualquer outro no nosso mercado.
O resto são os seus dados e as suas integrações. Um primeiro ciclo completo — estrutura, recursos, disponibilidade, restrições, geração, verificação, publicação — costuma demorar algumas semanas, e o maior consumidor é a recolha da disponibilidade dos docentes e não algo que o software faça. Os anos seguintes são dramaticamente mais curtos, porque a estrutura é transportada e apenas as alterações precisam de atenção.
O resumo honesto: raramente é o software que torna uma migração longa. Quem lhe disser o contrário está a vender-lhe a metade fácil.
Perguntas a fazer a quem estiver a avaliar
- Podem importar o nosso horário existente e em que formato o precisam?
- O que acontece às ligações que os nossos estudantes já guardaram?
- A vossa interface de integração está documentada publicamente, para que os nossos programadores a possam avaliar antes de nos comprometermos? A nossa está.
- Podemos executar os dois sistemas em paralelo durante um período?
- Como é o segundo ano — quanto deste trabalho se repete?
Quer ver isto a funcionar?
Marque uma apresentação online de 45 minutos e percorreremos a solução com base no problema de planeamento de horários da sua própria instituição.