SCORM vs xAPI (Tin Can): quale standard scegliere per l'eLearning

Cos'è xAPI (Experience API)

A differenza di SCORM, che vive esclusivamente dentro una piattaforma LMS, xAPI può registrare attività ovunque avvengano: in un'app mobile, in un simulatore, in una sessione di training in presenza registrata manualmente, in un ambiente 3D. Ogni evento diventa uno statement — una frase strutturata che descrive chi ha fatto cosa — e confluisce nel Learning Record Store, il database che sostituisce e amplia il registro interno dell'LMS.

Per una definizione completa di SCORM e del suo funzionamento, il punto di partenza è la nostra guida a SCORM.

SCORM vs xAPI: le differenze

La differenza sostanziale è nel cosa e nel dove viene tracciato. SCORM registra pochi dati essenziali (completamento, punteggio, tempo) e solo dentro l'LMS. xAPI registra qualsiasi cosa, ovunque.

Tin Can API: perché due nomi per lo stesso standard

xAPI e Tin Can API sono lo stesso standard. "Project Tin Can" era il nome del progetto di ricerca commissionato da ADL — lo stesso ente che mantiene SCORM — per progettarne il successore. Alla pubblicazione ufficiale, nel 2013, lo standard è stato battezzato Experience API (xAPI), ma il nome di lavorazione era ormai diffuso e i due termini convivono ancora oggi. Nella documentazione tecnica recente si usa xAPI; "Tin Can" sopravvive soprattutto nei materiali commerciali di alcuni vendor.

Quando SCORM è sufficiente

Nonostante l'età, SCORM resta lo standard giusto per la maggior parte dei corsi aziendali. Conviene sceglierlo quando:

• il corso è lineare: moduli in sequenza, quiz finale, attestato;
• i dati che servono sono completamento e punteggio, tipicamente per obblighi di conformità (sicurezza sul lavoro, GDPR, compliance);
• il contenuto deve girare su LMS diversi e non controllabili — ad esempio quando si vende un corso a più aziende clienti, ciascuna con la propria piattaforma: SCORM 1.2 è l'unico formato supportato praticamente ovunque;
• non c'è budget o necessità per un Learning Record Store.

In questi scenari xAPI aggiungerebbe complessità senza benefici misurabili. La scelta dello standard dipende anche dalla piattaforma di destinazione: ne parliamo nella guida all'integrazione tra SCORM e LMS.

Quando serve xAPI: simulazioni e formazione esperienziale

SCORM mostra i suoi limiti nel momento in cui la formazione smette di essere un corso e diventa un'esperienza. In una simulazione interattiva — un ambiente 3D in cui l'operatore smonta un macchinario, gestisce un'emergenza, prende decisioni con conseguenze — le domande interessanti non sono "ha finito? che voto ha preso?", ma:

• quali decisioni ha preso, e in quale ordine;
• quale percorso ha seguito dentro lo scenario, e dove ha esitato;
• quanti tentativi ha impiegato su ogni singola procedura, non sul corso intero;
• come si confrontano le sue performance con quelle del resto del team, nel tempo.

Questo livello di dettaglio con SCORM semplicemente non esiste: lo standard non ha il vocabolario per descriverlo. xAPI sì — ogni azione nella simulazione può generare uno statement, e l'analisi dei dati nel LRS trasforma la formazione in una fonte di analytics operative.

È lo scenario tipico dei progetti che sviluppiamo in Unity: simulazioni WebGL che devono sia integrarsi con l'LMS aziendale via SCORM, sia tracciare interazioni granulari. I due standard non si escludono — un contenuto può esporre l'interfaccia SCORM verso l'LMS e inviare statement xAPI a un LRS in parallelo. Come funziona tecnicamente lo raccontiamo nella pagina su Unity WebGL e SCORM.

E cmi5?

Chi esplora il confronto SCORM/xAPI incontra prima o poi cmi5: è un profilo di xAPI che definisce come un LMS deve lanciare e tracciare contenuti xAPI, colmando l'assenza di regole di packaging che SCORM invece ha. In pratica: xAPI definisce il linguaggio, cmi5 definisce le regole di ingaggio con l'LMS. L'adozione è ancora limitata, ma è la direzione in cui lo standard si sta consolidando — un progetto che parte oggi con xAPI dovrebbe valutare la conformità cmi5.

Domande frequenti