Cómo implantar laboratorios virtuales en una red de centros

La mayor parte de la tecnología educativa se diseña, se promociona y se vende como si el comprador fuera un único centro. En realidad, buena parte de ella la adquiere alguien responsable de veinte colegios, o de ciento veinte, y su problema no es el que aborda la presentación comercial. No se pregunta si el software es bueno. Se pregunta si seguirá siéndolo en un centro cuyo alumnado, horario, capacidad técnica y red informática no se parecen en nada a los del centro donde se pilotó.

Trabajamos con redes de centros y hemos visto implantaciones que salen bien y otras que salen mal. El patrón se repite lo suficiente como para merecer que lo pongamos por escrito.

¿Por qué fracasan las implantaciones en toda una red?

Rara vez porque el software fuera malo. Normalmente por una de estas cuatro razones.

El centro piloto no era representativo. Los pilotos acaban, de forma natural, en el centro que tiene un jefe de departamento de ciencias entusiasta, una buena red y un técnico de laboratorio al que le gustan las novedades. Ese centro consigue que casi cualquier cosa funcione. Su éxito predice muy poco sobre el centro que tiene dos interinos de larga duración y una wifi saturada.

La implantación se anunció en lugar de adoptarse. La compra centralizada puede adquirir licencias. No puede comprar la disposición de un jefe de departamento a reestructurar su programación didáctica. El software impuesto desde los servicios centrales sin la implicación de los departamentos produce sistemáticamente muchas licencias y poco uso, que es el resultado más caro posible.

Nadie definió qué era el éxito antes de empezar. Si la medida de éxito del piloto es recibir «comentarios positivos», el piloto tendrá éxito y no le dirá nada. Las redes que obtienen valor definen indicadores que realmente podrían no cumplirse.

La variabilidad técnica se descubrió tarde. El parque de dispositivos de una red nunca es uniforme, por mucho que la estrategia de TI diga lo contrario. Descubrir en la tercera semana de curso que los Chromebooks de un centro son cuatro años más antiguos que los de los demás es un problema recuperable en un piloto y muy serio a escala.

¿Cómo debería estructurar un piloto una red de centros?

El instinto es elegir un centro y probarlo durante todo un curso. Nosotros sugerimos lo contrario: elija tres centros que se contradigan entre sí y hágalo durante un trimestre.

Tres, porque un centro le dice si el software funciona y tres le dicen si funciona en toda su variabilidad real. Elija deliberadamente por diferencia: el departamento de ciencias más sólido y el más tensionado, los laboratorios mejor dotados y los peores y, si la red es internacional, más de un currículo. Si el software sobrevive a su caso más difícil, la implantación es un ejercicio de calendario. Si solo funciona en el caso fácil, lo habrá aprendido al coste de un trimestre y no de un curso entero.

Un trimestre en lugar de un curso, porque la señal útil llega pronto. Si un departamento no ha integrado la herramienta en su programación en un trimestre, un segundo trimestre no lo arreglará, y habrá quemado un año de presupuesto para descubrir algo que la semana ocho ya le habría dicho.

¿Qué debería medir?

Cuatro cosas, todas ellas fáciles de recoger para una red, y ninguna de ellas es la satisfacción.

Profundidad de uso, no activación de licencias. Cuántos alumnos completaron varias prácticas, no cuántos entraron una vez. La activación es una métrica de vanidad y los proveedores la citan porque les favorece.
Tiempo del profesorado. Pida a los departamentos que estimen las horas dedicadas a preparar el laboratorio, supervisar y corregir, antes y después. Será una estimación aproximada y aun así será la cifra que convenza a su director financiero.
Evidencia de destreza práctica. Si la plataforma evalúa el proceso y no las respuestas, dispondrá de datos por alumno sobre técnica y seguridad que antes no podía recoger de ninguna manera. Merece la pena examinarlos por sí mismos, al margen de la decisión de compra.
Acceso. En concreto: ¿participaron los alumnos que normalmente se pierden el trabajo práctico? El alumnado con dificultades de asistencia, necesidades médicas, ansiedad ante los entornos de laboratorio o necesidades educativas especiales es el grupo en el que los laboratorios virtuales producen con más frecuencia un efecto visible en los datos.

¿La compra debe ser centralizada o delegada?

Centralizada para el contrato, delegada para la pedagogía. Esa separación importa más de lo que parece.

Las redes tienen un poder de compra real y deberían usarlo: una negociación, una evaluación de protección de datos, una integración con el sistema de gestión escolar (MIS) o el LMS, una revisión de seguridad. Hacer que veinte centros realicen cada uno su propia diligencia debida sobre el proveedor desperdicia el tiempo de veinte personas y produce veinte respuestas distintas a la misma pregunta de protección de datos, lo que es un problema de gobernanza en ciernes. Nuestra lista de preguntas para plantear a los proveedores de tecnología educativa está pensada para aplicarse una sola vez, de forma centralizada.

Pero la decisión sobre cómo encaja una herramienta en la programación didáctica corresponde al departamento que la imparte. Una red que impone patrones de uso concretos a centros con alumnados y currículos distintos está tomando una decisión para la que no tiene información. Compre de forma centralizada y después deje que los departamentos decidan cuánto la usan y cuándo.

¿Qué debería preguntar a los proveedores que un centro aislado no preguntaría?

Cinco preguntas que solo importan a escala de red:

¿Los informes se consolidan? ¿Puede ver un centro, un departamento, una zona y el conjunto de la red, o alguien tiene que exportar veinte hojas de cálculo y fusionarlas?
¿Se pueden compartir contenidos entre centros? Si un docente de un centro crea algo bueno, ¿pueden usarlo los demás centros de la red o el trabajo se queda atrapado donde se hizo?
¿Cuál es el equipo mínimo real, con sinceridad? No la especificación recomendada. La máquina más antigua en la que funciona de verdad, porque usted tiene algunas de esas.
¿Cómo escala la formación inicial? Prometer formación impartida por el proveedor para tres centros es fácil. Pregunte qué ocurre en el centro número quince y si pueden formar a sus formadores.
¿Qué pasa con nuestros datos si nos vamos? Pregúntelo antes de firmar, no durante la salida.

¿Cómo escalar tras un piloto exitoso?

Por oleadas, y lideradas por los centros piloto y no por los servicios centrales.

El mecanismo más eficaz que hemos visto es que un jefe de departamento de ciencias de un centro piloto hable con el jefe de departamento de un centro candidato. Resulta más convincente que cualquier cosa que puedan decir un proveedor o un equipo central, porque las inquietudes que plantea son las que solo se le ocurren a quien está en el aula. Las redes que incorporan esto a la implantación, con una sesión breve por oleada dirigida por docentes, obtienen curvas de adopción completamente distintas de las de las redes que envían un correo anunciando licencias.

Cuente con que la segunda oleada saque a la luz problemas que la primera no reveló. Es la oleada en la que aparecen los problemas de red, los choques de horarios y los departamentos que necesitan otra implementación. Reserve tiempo para ello en lugar de tratarlo como un fracaso del piloto.

La cuestión de fondo

La ventaja de una red de centros no es que pueda comprar más barato. Es que puede realizar una comparación genuina, la misma intervención en el mismo trimestre en centros que difieren en aspectos que usted conoce, y llegar a una conclusión basada en evidencias a la que ningún centro aislado podría llegar por su cuenta. La mayoría de las redes no aprovechan esa ventaja y compran a partir de una demo, como todo el mundo.

Si va a tener la capacidad de llevar a cabo una implantación controlada, merece la pena diseñarla bien.