De la primera emisión a la operación institucional

La primera emisión suele ser un momento visible. Después de semanas o meses de diseño, la institución finalmente puede mostrar una microcredencial, verificarla, entregarla a sus primeros participantes y comprobar que el modelo funciona.

Ese momento es importante. Pero también puede generar una falsa sensación de conclusión. Porque emitir una primera microcredencial demuestra que la tecnología funciona y que existe una decisión institucional para comenzar. No demuestra todavía que la universidad haya construido una capacidad sostenible para operar cientos o miles de emisiones en distintas facultades, programas y áreas.

La diferencia aparece inmediatamente después.

Durante la etapa de diseño, las conversaciones suelen concentrarse en gobernanza, criterios académicos, estándares, identidad institucional, tipos de credencial y objetivos estratégicos. Cuando comienza la operación, las preguntas cambian:¿Quién solicita una emisión?

• ¿Quién confirma que los participantes realmente cumplieron los criterios?
• ¿Quién autoriza?
• ¿Quién ejecuta la emisión?
• ¿Qué ocurre si un nombre está mal escrito?
• ¿Quién puede corregir una credencial?
• ¿Qué sucede si una emisión debe revocarse?
• ¿Quién atiende al estudiante cuando algo no funciona como esperaba?

Ahí comienza una segunda etapa, menos visible que el lanzamiento, pero probablemente más determinante: convertir el modelo institucional en operación cotidiana.

Las experiencias internacionales muestran que esta transición requiere algo más que configurar una plataforma. Requiere incorporar las microcredenciales a los procesos reales de la universidad.

Del modelo institucional a la operación real

Una estrategia puede estar correctamente diseñada y aun así resultar difícil de operar. Esto sucede porque las decisiones estratégicas y las decisiones operativas pertenecen a niveles distintos.

Una universidad puede haber definido perfectamente:

• qué considera una microcredencial;
• qué criterios académicos deben cumplirse;
• qué áreas pueden proponerlas;
• qué estándares utilizar;
• qué información debe contener cada emisión.

Pero después necesita responder preguntas mucho más concretas:

• ¿cómo se inicia una solicitud?
• ¿qué evidencia debe acompañarla?
• ¿quién revisa esa evidencia?
• ¿cuándo una solicitud se considera autorizada?
• ¿quién recibe la lista definitiva de participantes?
• ¿qué datos deben validarse antes de emitir?
• ¿quién conserva la trazabilidad de la decisión?

La experiencia internacional muestra que, conforme las microcredenciales pasan del piloto a la operación, las instituciones comienzan a formalizar precisamente estas responsabilidades.
La University of British Columbia, por ejemplo, cuenta con procesos diferenciados para el desarrollo y aprobación de programas no crediticios y microcertificados. Las facultades, oficinas académicas, unidades de educación continua y autoridades universitarias participan en etapas distintas del proceso, con funciones específicas para desarrollo, revisión, aprobación y posterior implementación.[1]

No se trata necesariamente de copiar este modelo. 
La enseñanza relevante es otra: la estrategia necesita convertirse en procedimiento.

Las microcredenciales atraviesan varias áreas

Una microcredencial difícilmente pertenece a una sola oficina. Puede originarse en educación continua, una facultad o un área académica. Pero para llegar correctamente al estudiante puede involucrar también:

• responsables académicos;
• servicios escolares;
• calidad;
• educación digital;
• tecnologías de información;
• comunicación;
• vinculación;
• finanzas;
• atención a participantes.

University College Dublin documentó este fenómeno durante la implementación de su programa de microcredenciales. El desarrollo académico involucró profesores y especialistas en tecnología educativa, mientras que áreas de registro, admisiones, pagos, expedientes, evaluación, calidad, finanzas, comunicación y sistemas participaron para integrar las microcredenciales a la operación universitaria.[2]

El punto es importante. Que participen muchas áreas no es una debilidad. Es consecuencia natural de incorporar un nuevo tipo de reconocimiento académico a una institución compleja.

El problema surge cuando la participación depende únicamente de conversaciones informales. Cuando todos participan, pero nadie sabe exactamente dónde comienza y termina su responsabilidad, la operación depende de acuerdos personales.

Esto funciona durante un piloto. Es mucho más difícil sostenerlo cuando:

• aumenta el volumen;
• se incorpora otra facultad;
• aparece un nuevo responsable;
• surge una incidencia;
• o la institución necesita demostrar cómo se tomó determinada decisión.

Por eso, una de las primeras señales de madurez consiste en definir responsabilidades por etapa y no únicamente áreas participantes.

El flujo de una credencial debe convertirse en proceso institucional

No existe un flujo universal que todas las universidades deban copiar.

Pero sí existe una necesidad universal: definir qué ocurre desde que una credencial es solicitada hasta que puede ser utilizada y verificada por su titular.

Un flujo institucional podría contemplar, por ejemplo:
Solicitud → validación académica → autorización → preparación de datos → emisión → entrega → verificación → eventual corrección o revocación.

Cada universidad deberá adaptar estas etapas a su estructura. Lo importante es que las reglas sean explícitas. Por ejemplo:

Solicitud

¿Quién puede solicitar una emisión?:  ¿Un profesor?, ¿Una coordinación académica?, ¿Una dirección de educación continua?, ¿Cualquier facultad?

Validación

¿Qué debe demostrar el área solicitante?: ¿Que existe un programa autorizado?, ¿Que se cumplieron los criterios de evaluación?, ¿Que la lista de participantes es definitiva?

Autorización

¿Quién tiene atribuciones para permitir que la credencial utilice la identidad institucional?

Emisión

¿Quién ejecuta materialmente el proceso?
¿Existe revisión previa de datos?
¿Se requiere una segunda validación?

Entrega

¿Cómo sabe el estudiante que recibió una credencial?
¿Quién atiende dudas sobre acceso, uso o presentación?

Cambios posteriores

¿Qué ocurre si la institución detecta un error después de emitir?

En Nueva Zelanda, donde las microcredenciales forman parte del marco nacional de cualificaciones y credenciales, NZQA distingue explícitamente responsabilidades de desarrollo, aprobación, acreditación, entrega y revisión, y exige que los proveedores mantengan sus enfoques de operación actualizados cuando cambian los contenidos, las condiciones de entrega o los resultados de las revisiones.[3]

La tecnología puede automatizar buena parte de este recorrido. Pero no puede decidir por la universidad:

• quién tiene autoridad;
• qué constituye evidencia suficiente;
• qué excepciones son aceptables;
• o cuándo debe modificarse una emisión.

Esas siguen siendo decisiones institucionales.

Las excepciones revelan la madurez del modelo

Los pilotos suelen trabajar con casos ideales. Listas pequeñas. Responsables conocidos. Datos revisados manualmente. Participantes acompañados directamente por el equipo del proyecto.

La operación cotidiana es diferente. Aparecen situaciones como:

• un nombre incorrecto;
• una persona incluida por error;
• una duplicidad;
• una credencial que debe revocarse;
• un participante que asegura haber cumplido los requisitos pero no aparece en la lista;
• un cambio posterior en los criterios de un programa;
• un responsable que deja su puesto;
• una facultad que interpreta de manera diferente una política institucional;
• una emisión realizada con información incompleta.

Estas situaciones no significan necesariamente que el modelo esté mal diseñado. Significan que comenzó a operar en condiciones reales.
Aquí aparece una distinción importante:
Un modelo institucional no demuestra su madurez cuando todo funciona como estaba previsto, sino cuando sabe qué hacer cuando algo no ocurre como estaba previsto.

Por eso las excepciones deberían formar parte del diseño operativo.

Algunas preguntas que conviene resolver desde el principio son:

• ¿qué errores permiten corrección?
• ¿qué situaciones requieren nueva emisión?
• ¿quién puede autorizar una revocación?
• ¿cómo queda documentado el motivo?
• ¿cómo se informa al titular?
• ¿qué sucede con la credencial anterior?
• ¿quién decide cuando existen interpretaciones distintas?

Los marcos internacionales de calidad están avanzando precisamente hacia esta lógica de operación continua. La recomendación europea sobre microcredenciales no se limita a promover su creación: insiste en mecanismos de calidad, gobernanza, experimentación, cooperación entre actores y actualización de los modelos conforme evolucionan las necesidades.[4]

La operación institucional no consiste en evitar todos los errores. Consiste en saber cómo responder a ellos de manera consistente.

El soporte también forma parte del modelo

Cuando se habla de soporte en proyectos tecnológicos suele pensarse inmediatamente en: “¿Qué hacemos si la plataforma falla?”

Pero en microcredenciales, la mayor parte de las incidencias no necesariamente serán tecnológicas. Un estudiante puede preguntar:

• ¿por qué no recibí mi credencial?
• ¿puedo corregir mi nombre?
• ¿cómo la presento ante un empleador?
• ¿qué hago si perdí acceso al correo con el que me registré?

Un responsable académico puede preguntar:

• ¿puedo emitir para esta actividad?
• ¿qué criterios debo documentar?
• ¿quién autoriza esta modificación?
• ¿qué hago si un participante solicita una corrección?

Un área administrativa puede necesitar saber:

• qué información conservar;
• quién puede consultar una emisión;
• cuándo debe escalar una incidencia;
• qué responsable debe tomar la decisión final.

Por eso, soporte no debería entenderse únicamente como mesa de ayuda tecnológica. La institución necesita distinguir al menos tres niveles:

1. soporte tecnológico, relacionado con el funcionamiento de las herramientas;
2. soporte operativo, relacionado con procesos, solicitudes y ejecución;
3. soporte académico o institucional, relacionado con criterios, autorizaciones y decisiones.

Cuando estas responsabilidades no se distinguen, cualquier incidencia termina llegando a las mismas personas. Y esas personas terminan convirtiéndose en el verdadero sistema operativo del proyecto.

La coordinación no debería depender de personas específicas

En las primeras etapas existe una situación muy común: dos o tres personas conocen prácticamente todo. Saben quién autoriza. Conocen la plataforma. Recuerdan por qué se tomó cada decisión. Saben a quién llamar cuando aparece una excepción. Pueden resolver problemas rápidamente.

Esto puede hacer que el proyecto parezca extraordinariamente eficiente. Pero también representa una fragilidad.

¿Qué ocurre si una de esas personas cambia de puesto?
¿Qué sucede cuando una nueva facultad quiere emitir?
¿Puede alguien reconstruir una decisión tomada seis meses atrás?
¿Existe documentación suficiente para incorporar a un nuevo responsable?
¿Puede la institución aumentar diez veces el volumen sin aumentar diez veces la dependencia de esas mismas personas?

Las experiencias recogidas por 1EdTech en programas de credenciales de distintos tipos muestran la importancia de crear comités internos, involucrar diferentes actores institucionales, comenzar con alcances manejables y construir mecanismos de mejora continua antes de escalar.[5]

La documentación deja entonces de ser un requisito administrativo. Se convierte en infraestructura organizacional.

Una operación madura debería poder conservar, al menos:

• definición de roles;
• procedimientos;
• criterios de autorización;
• rutas de escalamiento;
• registro de excepciones;
• responsables vigentes;
• políticas de corrección y revocación;
• historial de decisiones relevantes.

El objetivo no es burocratizar el proceso. Es evitar que el conocimiento institucional permanezca exclusivamente en la memoria de unas pocas personas.

Escalar no significa únicamente emitir más

Existe una tentación natural de medir el éxito mediante volumen: “Ya emitimos 100 microcredenciales.”, “Llegamos a 1,000.”, “Tenemos diez programas.” Estos indicadores son útiles. Pero no muestran por sí solos si la institución realmente desarrolló capacidad operativa.

Una forma más exigente de evaluar la madurez sería preguntarse:

• ¿podemos repetir el proceso de manera consistente?
• ¿sabemos quién responde por cada etapa?
• ¿podemos incorporar una nueva facultad sin reinventar el modelo?
• ¿las excepciones tienen procedimientos definidos?
• ¿los estudiantes saben dónde solicitar ayuda?
• ¿los responsables pueden cambiar sin detener la operación?
• ¿podemos reconstruir por qué se tomó una decisión determinada?
• ¿el modelo seguirá funcionando cuando el volumen crezca?

Estas preguntas cambian la definición de éxito.

La primera emisión deja de ser la meta. Se convierte en el inicio de una capacidad institucional.