Hace ya varios años que xAPI se perfiló como un estándar potente para trazar la actividad de aprendizaje. A lo largo del tiempo se le ha conocido como TinCan o Experience API, y habitualmente se habla de ella como un sustituto de SCORM. Y aunque ha pasado el tiempo aún es habitual encontrarse con perfiles -sobre todo no muy técnicos- que tienen dudas sobre su funcionamiento y, en realidad, sobre qué es exactamente. Aquí recopilo algunos datos generales que pueden ayudar a tomar decisiones sobre ese tipo de trazabilidad en un proyecto de formación corporativa.

xAPI vs SCORM

Que xAPI es un sustituto de SCORM es cierto solo parcialmente. SCORM viene de una época en la que el análisis de datos de formación equivalía a registrar lo que se hacía dentro de un LMS, un paradigma anterior a la demanda masiva de interoperabilidad de hoy día. Es un estándar casi universalmente aceptado, pero tiene muy limitado el tipo de información que transmite. xAPI permite, en potencia, registrar todo lo que se hace fuera del LMS: cursos presenciales, búsquedas en Google, consulta de páginas web, actividad en redes sociales… Además, facilita conectar sistemas externos para que el aprendizaje formal no quede circunscrito a un LMS corporativo.

Así pues, xAPI va sobre interconectar sistemas, no hacer seguimiento de contenidos. Con SCORM puedes saber en qué punto está una persona respecto a un objetivo que, normalmente, se mide en actividades superadas (con más o menos nivel de detalle) dentro de un LMS. Con xAPI es posible conectar esa actividad con otros sistemas que registren, por ejemplo, lo que hace una persona en su trabajo (una aplicación cualquiera que utilice para trabajar). Esto permite relacionar ambas fuentes de datos de dos formas:

• vincular el rendimiento con la formación: si una persona supera el curso X, es de esperar que se vea una mejora en los registros de las tareas relacionadas con lo aprendido.
• vincular la formación con el rendimiento: si hay registros que indican que una persona tiene problemas para hacer una tarea (por ejemplo, ha llamado varias veces a un servicio de soporte para preguntar por ella), se le puede ofrecer automáticamente una actividad formativa para reforzarla.

Vale, pero ¿qué es?

xAPI no es software, no es nada instalable ni configurable. Es una especificación, un documento que describe un lenguaje común para comunicar sistemas. La terminología que incluye se refiere a eventos relacionados con el aprendizaje y la formación. Por tanto, un sistema que registre algo que ha hecho un usuario (un vídeo que haya visto, una clase presencial a la que haya asistido…) puede convertirlo en una «sentencia» de este lenguaje común y enviarlo a otro sistema que sea capaz de entenderla.

Para que los sistemas puedan traducir sus datos al estándar xAPI deben contar con una API que entienda esas especificaciones, un elemento de software que pueda hacer de intérprete para los datos que salen y entran. Ese elemento puede existir ya desarrollado (varios LMS incluyen ya una API que lee xAPI), pero muchas veces habrá que desarrollarlo para que nuestros sistemas se hablen entre ellos.

Por ejemplo, si tengo una aplicación de RRHH donde se registra la gente que acude a un seminario, tendré que desarrollar una API que transforme ese dato al estándar xAPI y lo envíe a, pongamos, mi LMS, donde queda registrado junto al resto de información de eventos de aprendizaje de cada persona.

En resumen, mientras que SCORM hace que un paquete de software (un objeto de aprendizaje) se comunique con un LMS, xAPI permite que cualquier sistema se comunique con otro, siempre que ambos cuenten con una API que sepa traducir sentencias a este estándar.

Este envío puede producirse dentro de un sistema corporativo (dentro de un firewall) o a través de internet con una conexión segura, por lo que teóricamente pueden recogerse datos de cualquier sitio que disponga de una API que entienda este estándar.

¿Qué tipo de información maneja?

Básicamente cualquier cosa. Las sentencias de xAPI siguen un esquema persona-verbo-objeto-complementos que puede transmitir virtualmente lo que sea:

• Alicia abrió el excel «Parte horario»
• Alicia preguntó «¿Alguien sabe poner contraseña a un excel?» en Yammer
• Alicia consulto la ayuda de trabajo ‘Cómo cubrir un parte horario‘»
• Alicia llamó al servicio de soporte técnico el día D a la hora H.
• Alicia consultó «Manual básico de excel» en la intranet
• Alicia buscó ‘Cómo poner contraseña a un excel’ en Google
• Alicia se matriculó en el curso «Excel básico»

Siguiendo la pauta habitual con SCORM, tendríamos los datos del LMS sobre la matrícula y resultados del curso, y los datos que pudiéramos extraer de fuentes indirectas. Sin embargo, con los distintos sistemas enviando información, el conjunto cuenta una historia relevante para el diseño didáctico.

Es importante ver que no estamos hablando exclusivamente de actividades de formación: haciendo que los sistemas hablen entre ellos vinculamos formación con práctica. Esto da alas al apoyo al trabajo in situ, porque puedes, teóricamente, hacer que un sistema informe de que alguien ha hecho mal un determinado flujo de trabajo, para que otro sistema lea eso y ofrezca una ayuda de trabajo adecuada en el momento en que hace falta.

¿Y cuáles son las desventajas?

La principal es el desarrollo que necesita. Al ser un estándar de codificación, si quieres que tus sistemas lo usen tendrás que tener una API que traduzca los datos que manejan de forma nativa a ese estándar. Ya hay APIs para sistemas populares, pero dependiendo de los datos que manejes quizá no se ajusten a lo que necesitas. Si tu sistema dice «Fulanito ha asistido al curso X» y la API está preparada para recibir «Fulanito ha realizado el curso X», ya no se van a entender. De hecho, el problema más grande es el esfuerzo que requiere para unificar la terminología de cada sistema.

También requiere un sistema de almacenamiento para todos esos datos llamado LRS. El LRS es software que recibe e interpreta las sentencias enviadas por las API y las traduce al estándar xAPI. Puede usarse con conectividad ocasional, y puede registrar cualquier cosa (por ejemplo información de un giroscopio o de un acelerómetro). Puede funcionar como un componente añadido en un LMS, así que no es necesariamente una pieza más a añadir, pero en ese caso posiblemente esté limitado a las posibilidades de explotación de datos que ofrezca el LMS.

Algo a tener en cuenta (realmente no es una desventaja sino una precaución) es que al cruzar los datos de sentencias referidas a aprendizaje con las de resultados de trabajo vamos a encontrar muchas relaciones espurias. «Diez personas asistieron a un seminario y han subido sus ventas» es una conclusión tentadora, pero hay muchas variables que pueden estar mediando en esa relación. Es importante recordar que correlación y causa no son lo mismo, y someter los datos a un análisis riguroso.

Entonces, ¿vale la pena?

En términos de aprendizaje adaptado y de evaluación de impacto es un cambio enorme. Por otro lado, el esfuerzo de construcción es grande también. Desde mi punto de vista, tiene sentido si:

• tienes varios sistemas que pueden recoger información relevante para la formación.
• tienes una estrategia de aprendizaje adaptado que pasa por automatizar determinadas sugerencias y recursos personalizados en función de determinadas acciones de un trabajador.
• tienes una estrategia de evaluación de impacto real.
• si trabajas con proveedores externos y sus sistemas se ajustan al estándar (para que puedan reportar directamente a tu LRS).

Si tienes interés en profundizar más sobre xAPI, termino con dos recomendaciones: este estupendo MOOC para una visión completa, y este detallado artículo para una visión realista de las posibilidades.