CASO DE SUCESSO
Como ajudamos a EMASEA a criar conteúdo no formato SCORM em tempo recorde.
November 12, 2026
CONTEÚDO CRIADO POR:

Índice
Um SCO — Sharable Content Object, ou objeto de conteúdo compartilhável — é a menor unidade de conteúdo que um LMS consegue lançar e da qual consegue registar resultados dentro do padrão SCORM. Dito de forma curta: quando a sua plataforma anota que um funcionário concluiu algo, o que ele concluiu foi um SCO.
É um conceito técnico com consequências muito práticas para quem gere capacitação. A forma como se dividem os SCO de um curso decide o que o seu LMS consegue medir: se todo o curso for um único SCO, você só saberá se foi terminado ou não; se estiver repartido em seis, saberá exatamente em qual as pessoas travam. Essa decisão toma-se ao publicar o curso e depois é cara de desfazer.
O SCORM classifica tudo o que vai dentro de um pacote em dois tipos de recurso: assets e SCOs. E a fronteira entre ambos é uma só coisa.
Um asset é conteúdo estático que se mostra ao aluno: uma imagem, um PDF, um vídeo, uma folha de estilos. Apresenta-se e pronto. Um SCO também é feito de um ou vários arquivos, mas tem de conseguir comunicar com o LMS através da Runtime API. Essa capacidade de falar com a plataforma é a única coisa que converte um recurso em SCO.
A consequência é muito concreta: se você empacotar um PDF como asset, o seu LMS poderá mostrá-lo, mas não saberá se alguém o abriu. Para que fique registo, essa peça tem de ser um SCO.
| Critério | Asset | SCO |
|---|---|---|
| O que é | Um ou vários arquivos de conteúdo estático: uma imagem, um PDF, um vídeo, uma folha de estilos. | Uma unidade de instrução de um ou vários arquivos, pensada para ensinar algo concreto. |
| Fala com o LMS? | Não. Mostra-se ao aluno e não devolve nada. | Sim, e é obrigatório: é justamente o que o converte em SCO. |
| Pode ser rastreado? | Não. O LMS não sabe se foi visto nem quanto tempo. | Sim: estado, pontuação, tempo de sessão e ponto de avanço. |
| É o LMS que o lança? | Não diretamente. Costuma fazer parte de outro recurso. | Sim. É o que se abre quando o aluno clica no curso. |
| Para que serve | Material de apoio e recursos partilhados por vários SCO. | A peça formativa da qual você quer ter dados. |
A especificação impõe três obrigações a qualquer SCO. Se alguma falhar, o conteúdo verá-se na mesma mas o acompanhamento não funcionará:
API no SCORM 1.2 e API_1484_11 no SCORM 2004. Se não o localizar, não há acompanhamento possível.Initialize — LMSInitialize no 1.2 — antes de enviar ou pedir um único dado.Terminate — LMSFinish no 1.2 — em todos os caminhos de saída, incluindo o de fechar a aba sem avisar.E há uma regra de direção que explica boa parte dos problemas de tracking: a conversa é sempre iniciada pelo SCO. O LMS responde quando lhe perguntam, mas nunca pergunta ele. Se o SCO se cala, a plataforma não tem forma de descobrir o que aconteceu: simplesmente não regista nada.
Esta é a decisão prática mais importante à volta do conceito, e quase ninguém a toma conscientemente: herda-se do que a ferramenta de autoria faça por padrão. Convém decidi-la, porque cada SCO tem o seu próprio registo no LMS e isso define o nível de detalhe de todos os relatórios que verá depois.
A regra de ouro é a mesma que rege qualquer objeto de aprendizagem: um SCO deveria cobrir um único objetivo de aprendizagem, ser suficientemente pequeno para poder ser reutilizado noutro curso e suficientemente grande para ensinar algo por si só. Entre esses dois extremos, escolha conforme o que precisa de medir:
| Abordagem | O que você vê no LMS | Quando convém |
|---|---|---|
| Um único SCO para todo o curso | Só o resultado global: concluído ou não, e uma pontuação. | Cursos curtos, capacitação obrigatória de trâmite, ou quando o seu LMS dá problemas com a sequenciação. |
| Vários SCO, um por módulo | Progresso módulo a módulo: onde as pessoas abandonam e que parte custa mais. | Trilhas longas, capacitação por cargos e quando quiser reutilizar módulos soltos noutros cursos. |
| Um SCO por cada atividade pequena | Muito detalhe, mas o relatório torna-se difícil de ler. | Quase nunca: multiplica a manutenção e complica a sequenciação sem mudar nenhuma decisão. |
Cada SCO tem o seu próprio conjunto de dados no LMS, separado do dos restantes: estado de conclusão, pontuação, tempo de sessão, marcador de posição e um campo livre, cmi.suspend_data, onde o curso guarda o seu estado interno para poder ser retomado.
Daí derivam duas coisas que surpreendem muita gente da primeira vez:
Os SCO não falam entre si. Não existe um canal direto entre eles. Se o módulo 3 precisasse de saber o que o aluno respondeu no módulo 1, o padrão não o contempla: quem decide a ordem e as condições de passagem é a sequenciação declarada no imsmanifest.xml, não o conteúdo.
O campo de retoma tem um teto. Segundo a referência da especificação, cmi.suspend_data admite 4.096 caracteres no SCORM 1.2 e 64.000 no SCORM 2004 (3.ª e 4.ª edição). É a causa mais comum de um curso longo “perder” o ponto onde o aluno ficou: o conteúdo tenta guardar mais estado do que cabe, e o que sobra é descartado sem avisar.
Não é preciso escrever uma linha de código para que isto afete o seu trabalho. Estas são as decisões onde aparece:
A EMASESA, a empresa municipal de águas de Sevilha, utilizou o isEazy Author para criar os seus cursos SCORM em tempo recorde e publicá-los diretamente no seu LMS, com acompanhamento preciso do progresso por parte da equipe de RH.
Descubra como a EMASESA criou os seus cursos e-learning →
O SCO resolveu muito bem o problema para o qual foi desenhado — conteúdo portável entre plataformas —, mas tem fronteiras claras:
No dia a dia, quem desenha a capacitação não constrói SCOs à mão: gera-os a ferramenta de autoria ao publicar. O que sim decide é a configuração, e aí é onde convém saber o que se está a escolher.
O isEazy Author publica em SCORM 1.2 e SCORM 2004 gerando o pacote completo — manifesto, recursos e as chamadas de início, gravação e fecho de sessão — sem configuração técnica adicional. Isso evita as duas falhas que mais se repetem: cursos que ficam em “incompleto” porque nunca fecham a sessão, e cursos que não retomam onde o aluno ficou porque transbordam o campo de estado.
Um asset é conteúdo estático que se mostra ao aluno — uma imagem, um PDF, um vídeo — e que não comunica com a plataforma. Um SCO também é feito de arquivos, mas tem a obrigação de comunicar com o LMS através da Runtime API, e é essa capacidade que o converte em SCO. A consequência prática: de um asset não fica nenhum registo, enquanto de um SCO o LMS guarda estado de conclusão, pontuação, tempo e ponto de avanço.
Depende do detalhe que você precisa nos relatórios, porque cada SCO gera o seu próprio registo no LMS. Com um único SCO para todo o curso só saberá se foi concluído e com que nota. Com um SCO por módulo verá em que ponto as pessoas abandonam e poderá reutilizar módulos soltos noutros cursos. Descer ao nível de atividade individual quase nunca compensa: multiplica a manutenção sem mudar nenhuma decisão. A regra habitual é um SCO por objetivo de aprendizagem.
Não diretamente. Cada SCO tem o seu próprio conjunto de dados de execução, isolado do dos restantes, e o padrão não define nenhum canal de comunicação entre eles. O que existe é a sequenciação declarada no arquivo imsmanifest.xml, que permite condicionar o acesso a um SCO conforme os resultados de outro. Se precisa que o conteúdo reaja a decisões tomadas num módulo anterior, isso resolve-se na sequenciação do SCORM 2004 ou passando para xAPI.
Estão aparentados mas não são o mesmo. Um objeto de aprendizagem é um conceito pedagógico: qualquer recurso digital reutilizável que sirva para aprender. Um SCO é a sua concretização técnica dentro do SCORM: um objeto de aprendizagem empacotado de forma que um LMS possa lançá-lo e rastreá-lo. Todo SCO é um objeto de aprendizagem, mas muitos objetos de aprendizagem — um vídeo solto, um infográfico — não são SCO porque não comunicam com nenhuma plataforma.
Com conteúdo visual atraente e recursos prontos para uso. Selecione, personalize e pronto!
Teste gratuitamenteSolicite uma demonstração
