SCO (Sharable Content Object)

¿Qué es un SCO (Sharable Content Object)?

Un SCO —Sharable Content Object, u objeto de contenido compartible— es la unidad más pequeña de contenido que un LMS puede lanzar y de la que puede registrar resultados dentro del estándar SCORM. Dicho en corto: cuando tu plataforma anota que un empleado ha completado algo, lo que ha completado es un SCO.

Es un concepto técnico con consecuencias muy prácticas para quien gestiona formación. La forma en que se dividen los SCO de un curso decide qué puede medir tu LMS: si todo el curso es un único SCO, solo sabrás si lo ha terminado o no; si está repartido en seis, sabrás exactamente en cuál se atasca la gente. Esa decisión se toma al publicar el curso y después es cara de deshacer.

SCO frente a asset: la diferencia que lo decide todo

SCORM clasifica todo lo que va dentro de un paquete en dos tipos de recurso: assets y SCOs. Y la frontera entre ambos es una sola cosa.

Un asset es contenido estático que se le muestra al alumno: una imagen, un PDF, un vídeo, una hoja de estilos. Se presenta y ya está. Un SCO también está hecho de uno o varios archivos, pero tiene que poder comunicarse con el LMS a través de la Runtime API. Esa capacidad de hablar con la plataforma es lo único que convierte a un recurso en SCO.

La consecuencia es muy concreta: si empaquetas un PDF como asset, tu LMS podrá mostrarlo, pero no sabrá si alguien lo ha abierto. Para que quede registro, esa pieza tiene que ser un SCO.

Qué tiene que hacer un SCO para ser un SCO

La especificación impone tres obligaciones a cualquier SCO. Si falla alguna, el contenido se verá igual pero el seguimiento no funcionará:

1. Encontrar la API del LMS. El SCO busca un objeto JavaScript en la ventana que lo contiene. Se llama API en SCORM 1.2 y API_1484_11 en SCORM 2004. Si no lo localiza, no hay seguimiento posible.
2. Abrir la sesión antes de cualquier otra cosa. Todo SCO debe llamar a Initialize —LMSInitialize en 1.2— antes de enviar o pedir un solo dato.
3. Cerrarla siempre. Debe llamar a Terminate —LMSFinish en 1.2— en todos los caminos de salida, incluido el de cerrar la pestaña sin avisar.

Y hay una regla de dirección que explica buena parte de los problemas de tracking: la conversación la inicia siempre el SCO. El LMS responde cuando le preguntan, pero nunca pregunta él. Si el SCO se calla, la plataforma no tiene forma de averiguar qué ha pasado: simplemente no registra nada.

Un solo SCO o varios: cómo decidir la granularidad

Esta es la decisión práctica más importante alrededor del concepto, y casi nadie la toma a conciencia: se hereda de lo que haga por defecto la herramienta de autor. Conviene decidirla, porque cada SCO tiene su propio registro en el LMS y eso define el nivel de detalle de todos los informes que verás después.

La regla de oro es la misma que rige cualquier objeto de aprendizaje: un SCO debería cubrir un único objetivo de aprendizaje, ser lo bastante pequeño para poder reutilizarse en otro curso y lo bastante grande para enseñar algo por sí solo. Entre esos dos extremos, elige según lo que necesites medir:

Qué guarda cada SCO y dónde está el límite

Cada SCO tiene su propio conjunto de datos en el LMS, separado del de los demás: estado de finalización, puntuación, tiempo de sesión, marcador de posición y un campo libre, cmi.suspend_data, donde el curso guarda su estado interno para poder reanudarse.

De ahí se derivan dos cosas que sorprenden a mucha gente la primera vez:

Los SCO no se hablan entre sí. No existe un canal directo entre ellos. Si el módulo 3 necesitara saber qué respondió el alumno en el módulo 1, el estándar no lo contempla: quien decide el orden y las condiciones de paso es la secuenciación declarada en el imsmanifest.xml, no el contenido.

El campo de reanudación tiene un tope. Según la referencia de la especificación, cmi.suspend_data admite 4.096 caracteres en SCORM 1.2 y 64.000 en SCORM 2004 (3.ª y 4.ª edición). Es la causa más común de que un curso largo «pierda» el punto donde se quedó el alumno: el contenido intenta guardar más estado del que cabe, y lo que sobra se descarta sin avisar.

Qué implica el SCO para los responsables de formación

No hace falta escribir una línea de código para que esto afecte a tu trabajo. Estas son las decisiones donde aparece:

• Define qué vas a poder medir antes de encargar el curso. Si necesitas saber en qué módulo abandona la gente, pide explícitamente un paquete con un SCO por módulo. Pedirlo después implica republicar y, en muchos LMS, perder el histórico de quienes ya lo habían empezado.
• Pregunta por la versión. SCORM 1.2 es universalmente compatible pero más limitado; SCORM 2004 permite secuenciación entre SCO y un modelo de datos más rico. Elige según lo que admita tu plataforma, no según lo más nuevo.
• Comprueba la compatibilidad del LMS. El seguimiento solo funciona si la plataforma expone correctamente el adaptador de la API. Un LMS compatible con SCORM garantiza que el SCO encontrará con quién hablar.
• Desconfía de los cursos sin estado. Si un contenido aparece siempre como «no iniciado» pese a que la gente lo abre, lo más probable es que se haya publicado como asset y no como SCO, o que no esté cerrando la sesión.

EMASESA, la empresa municipal de aguas de Sevilla, utilizó isEazy Author para crear sus cursos SCORM en tiempo récord y publicarlos directamente en su LMS, con seguimiento preciso del progreso por parte del equipo de RR. HH.
Descubre cómo EMASESA creó sus cursos e-learning →

Limitaciones del modelo SCO

El SCO resolvió muy bien el problema para el que se diseñó —contenido portable entre plataformas—, pero tiene fronteras claras:

• Datos aislados. Cada SCO guarda lo suyo y no comparte nada con el resto, lo que complica cualquier itinerario que dependa de decisiones tomadas en un módulo anterior.
• Solo dentro del LMS y del navegador. El SCO necesita un reproductor SCORM que exponga la API. Fuera de ahí —una app nativa, una sesión presencial, una herramienta de terceros— no hay registro.
• La granularidad se congela al publicar. Cambiar de un SCO a seis no es editar el curso: es volver a empaquetarlo y volver a subirlo.
• No mide lo que ocurre fuera del curso. Para eso existe xAPI, que registra experiencias de aprendizaje sin depender de una ventana de navegador abierta contra un LMS.

El SCO en la práctica: qué resuelve la herramienta de autor

En el día a día, quien diseña la formación no construye SCOs a mano: los genera la herramienta de autor al publicar. Lo que sí decide es la configuración, y ahí es donde conviene saber qué se está eligiendo.

isEazy Author publica en SCORM 1.2 y SCORM 2004 generando el paquete completo —manifiesto, recursos y las llamadas de inicio, guardado y cierre de sesión— sin configuración técnica adicional. Eso evita los dos fallos que más se repiten: cursos que se quedan en «incompleto» porque nunca cierran la sesión, y cursos que no reanudan donde se quedó el alumno porque desbordan el campo de estado.