Desde hace algunos años, cada año se anuncia que “SCORM ha muerto” y que hay que abrir el paso a nuevas tecnologías. ¿Qué tanto hay de cierto en esas afirmaciones? ¿En verdad es necesario desechar el estándar SCORM como algo anticuado y “pasado de moda”? SCORM tiene fortalezas que le permiten brillar en entornos organizacionales que tienen un plan de capacitación estructurado y requieren obtener información de las interacciones.

¿Se le acabó el tiempo a SCORM?

Eso de proclamar la muerte de algo es sensacionalista o elogio (como diciendo “el rey ha muerto, viva el rey”).

La nota más antigua que conozco acerca de la “muerte de SCORM” data de 2011, cuando Philip Hutchison comentó en su artículo Is SCORM Dead? sobre un malentendido por un tuit que escribió: “Por lo que puedo leer entre líneas, #SCORM está muerto para la ADL”.

En el mismo artículo, Hutchison explica que su intención era comentar que ya no habrá desarrollo del modelo SCORM y que se privilegiaría el desarrollo de Tin Can (que entonces era un proyecto). Después de una serie de aclaraciones, termina su artículo afirmando que SCORM seguía siendo cool.

Pero desde entonces han aparecido múltiples publicaciones que proclaman “la muerte de SCORM”. Cada año. Desde 2011.

Otro ejemplo es Why SCORM 2004 failed & what that means for Tin Can cuando en 2013 hablaron de que SCORM (2004) estaba muriendo (o incluso ya estaba muerto). ¿A qué se debía tal proclamación? A que, según las estadísticas presentadas por el mismo artículo, el 75% de los paquetes SCORM estaban en la versión 1.2.

En realidad no se habla de la muerte de SCORM, sino de la vigencia de SCORM 1.2 y de la baja tracción que había cobrado SCORM 2004. También menciona que en esos años se hablaba más fuerte de Tin Can como sucesor de SCORM 2004.

Aun así, seguimos hablando de SCORM. Se publican ofertas laborales para personas que sepan “desarrollar en SCORM”. Las herramientas de autoría vigentes para elaborar e-learning siguen ofreciendo la opción de exportar a SCORM. Los principales LMS mantienen su compatibilidad con los paquetes SCORM en su núcleo. Se siguen escribiendo artículos sobre SCORM, sea para compararlo con xAPI o para matarlo de nuevo.

No está tan mal para un “muerto”.

Tal vez no muerto pero… ¿pasado de moda?

También se ha dicho que SCORM está “pasado de moda”. Supongo que es una forma de decir que está en desuso o que ha perdido vigencia.

Pero hay algo innegable. SCORM sigue funcionando. Permite registrar acciones que los usuarios quieren registrar, llevar un tracking, acorde con lo que los usuarios quieran rastrear. Hace posible mudarse a otras plataformas que lo soportan.

Hace unos meses hice algunos comentarios a un artículo donde se afirmaba que SCORM está “pasado de moda”. En esa ocasión mencioné que las críticas eran imprecisas porque en general se criticaban cosas distintas, como las funciones y alcances de los LMS o el tipo de tecnologías que sería necesario utilizar en el futuro.

Algunos desarrollos multimedia e interactivos. Todos compatibles con SCORM

¿Será que esas creencias falsas son generalizadas? Para dejar algunos puntos claros de una vez.

Por ejemplo, se hablaba de una supuesta vinculación con Flash y JavaScript, mientras que los cursos actuales trabajan (principalmente) con HTML5. Pero hay un pequeño detalle. HTML5 es un conjunto de tecnologías: JavaScript, CSS 3 y HTML. No hay conflicto real, solo desconocimiento.

Es evidente que no es un problema del protocolo SCORM, cuyo propósito es permitir la comunicación con las plataformas LMS y recopilar datos para llevar un tracking (registro) de las acciones de un estudiante. Las tecnologías de desarrollo pueden variar, pero la forma en que un paquete SCO se comunica con un LMS a través de SCORM se basa en las especificaciones del modelo.

Otro punto que se mencionaba era que, supuestamente, SCORM tiene problemas para trabajar con nuevos tipos de contenido, requeridos para los cursos que se requieren en la actualidad. Pero SCORM tiene poco que ver con los elementos usados en un paquete (sea video, audio, animaciones, etcétera). Con las etiquetas MIME type se pueden indicar los tipos de contenidos utilizados y reportados en el manifiesto. La forma en que dichos contenidos serán manejados depende de la configuración del servidor que distribuirá el contenido, no de SCORM ni del manifiesto.

También se hablaba de la falta de soporte para SCORM. Pero eso es otra noción equivocada. SCORM es un conjunto de estándares y especificaciones, no un producto que requiera “soporte”. El modelo tiene documentación propia y se requieren conocimientos específicos para configurarlo, del mismo modo que ocurre con otros estándares y especificaciones.

Es cierto, SCORM tiene ya sus años. Existen modelos nuevos (como Tin Can, el gran mencionado siempre) que manejan otro tipo de datos y acciones que se pueden registrar.

Pero entonces… ¿SCORM tendría que dejarse morir, hacerse a un lado?

Sin embargo… sigue vivo

Como lo mencionaba antes, SCORM sigue presente. Es claro que el ambiente donde brilla (y para el cual nació) son los entornos corporativos y académicos (universidades, por ejemplo). Justo donde están los LMS.

¿Por qué? Por lo dicho. Funciona. Sigue cumpliendo con requerimientos de los usuarios, sobre todo en sentido administrativo: registrar accesos a la plataforma, seguir la pista del tiempo de revisión de los cursos, identificar los puntos de abandono, resguardar las calificaciones de las evaluaciones, la cantidad de intentos, obtener reportes, estadísticas… entre muchas otras opciones que permite SCORM y no siempre son explotadas.

Por supuesto, siempre que se habla de la muerte de SCORM o de que es un modelo anticuado, se habla del futuro de xAPI (Tin Can) como una alternativa viable.

También nosotros lo hemos hecho, en el artículo ¿Qué es Tin Can y por qué te conviene saber al respecto? en el que Juan Carlos Huerta explica las ventajas de Tin Can. Pero nuestra perspectiva hace toda la diferencia: se afirma que es posible integrar Tin Can a LMS robustos, de modo que se puedan conservar las fortalezas de la capacitación interna basada en SCO, integrando la flexibilidad que brinda xAPI.

¿Entonces SCORM tiene futuro?

En el presente y en el mercado mexicano (y me arriesgaría a decir que en América Latina) donde el e-learning interactivo está cobrando momentum, SCORM es una herramienta que no ha perdido su fuerza.

Ocurre así porque está vinculado con un modelo de capacitación que requiere información precisa, datos sobre el uso, entre otras variables.

SCORM es hasta ahora, en ese paradigma, el modelo de referencia más útil y el de uso generalizado. Sí, más en su versión 1.2 pero ahora comienzan a verse algunas ventajas de la versión 2004 también.

Tin Can, xAPI, es parte de otro paradigma… en el que es preciso registrar más actividades y elementos provenientes de un mundo de información abundante y sobreoferta de educación y medios de aprendizaje. Pero xAPI no ha alcanzado la madurez aún. Por ejemplo, al tratar de integrar Tin Can en Moodle (en su versión 3.4) aún no se puede guardar información del avance de los cursos en las tablas de Moodle (hay formas de generar un registro, pero no se guarda la calificación en el libro de calificaciones de Moodle).

Además, creo que el desarrollo de xAPI también está ligado al desarrollo de modelos de capacitación que están evolucionando y están en pleno desarrollo.

¿Conclusión?

No obstante, diferentes desarrollos de e-learning basados en distintos paradigmas de capacitación pueden convivir. No se requiere aniquilar uno para que el otro florezca (o siga vivo).

Sabemos que Tin Can responderá a necesidades y requerimientos futuros y por eso estamos trabajando en desarrollos para Tin Can y LRS… así como su vinculación con los LMS, que permiten su integración con las necesidades administrativas organizacionales.

Considero que SCORM seguirá presente. Es muy posible que se mantenga vivo varios años más en su entorno nativo, que no es poca cosa. Y seguirán desarrollándose tecnologías que permitan incorporar nuevos modelos de aprendizaje. Pero quizá no es una cuestión de vida o muerte… sino de convivencia.