La implementación del nuevo sistema irá acompañada de un proceso de preparación para todos los equipos.

Se realizarán sesiones formativas prácticas, enfocadas en cómo el nuevo sistema apoyará el trabajo cotidiano. Más que aprender una herramienta, buscamos fortalecer nuevas formas de trabajo colaborativo, apoyadas en información integrada y procesos más simples.

Las señales tempranas que anticipan el resultado de una implementación del SIS

Scroll al inicio
Configurar el sistema replicando exactamente los procesos actuales

Cuando comienza la implementación, muchas áreas quieren que “configuremos el sistema como trabajamos hoy” y el argumento suele ser el evitar resistencia, facilitar la adopción y respetar las prácticas institucionales. El problema es que muchos procesos existentes fueron diseñados para sistemas antiguos, contienen excepciones acumuladas y reflejan acuerdos informales. Al replicarlos en el nuevo sistema se introduce una complejidad innecesaria desde el inicio. La consecuencia es que el SIS termina lleno de reglas excepcionales, configuraciones complejas, dependencias difíciles de mantener. El principio debería ser primero diseñar simplificando los procesos, luego configurar el sistema.

Subestimar la importancia del registro académico

En muchos proyectos el liderazgo se concentra en tecnología, finanzas y consultores externos y el registro académico queda en un rol secundario. El problema es que registro académico es el área que mejor entiende las reglas curriculares, los calendarios académicos, los requisitos de graduación, el historial estudiantil. Si el registro no lidera el diseño funcional, el sistema se configura sin reflejar correctamente la lógica académica. La consecuencia se ve en los problemas posteriores en matrícula, certificaciones, historial académico. El registro académico debe ser uno de los actores centrales del proyecto.

Permitir demasiadas excepciones durante el diseño

Durante la configuración aparecen solicitudes como “nuestra facultad necesita algo distinto”, “este programa tiene reglas especiales”, “este campus funciona diferente”. El problema es que cada excepción crea una nueva regla en el sistema, una nueva variante de proceso y, con el tiempo, el sistema se vuelve difícil de entender incluso para quienes lo configuraron. La consecuencia es que el SIS se vuelve complejo, difícil de mantener, difícil de capacitar. Hay que adoptar el principio de que “la excepción debe justificarse institucionalmente, no localmente” y sostenerla en la fase de diseño.

Descuidar la calidad del dato inicial

La migración de datos suele considerarse una tarea técnica y se asume que basta con extraer los datos del sistema antiguo y cargarlos en el nuevo. El problema es que los datos históricos suelen contener inconsistencias, estructuras obsoletas, registros incompletos. Si esos problemas no se corrigen antes de la migración, el nuevo sistema hereda el desorden. La consecuencia es que, después del go-live, aparecen inconsistencias en reportes, errores en historiales académicos, problemas en analítica institucional. La migración de datos debe incluir un proceso profundo y oportuno de limpieza y validación.

Tratar la capacitación como una actividad final

Muchas universidades planifican la capacitación cerca del go-live con la lógica de primero configuremos el sistema y luego enseñamos a usarlo. El problema es que los usuarios aprenden el sistema demasiado tarde y esto genera inseguridad, resistencia y dependencia del equipo del proyecto. La consecuencia es que, después del go-live aparecen errores operativos, uso incorrecto del sistema y procesos paralelos en Excel. La capacitación debe ser progresiva durante todo el proyecto y los usuarios deben aprender el sistema mientras se diseña.