Анатомия платформы видеообучения, от и до

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Платформа видеообучения состоит из девяти слоёв: авторинг, хранение контента, доставка видео, интерактивный плеер, отслеживание, LMS или LRS, оценивание, аналитика и отчётность. Поверх них идёт десятый, сквозной слой – стандарты, доступность и российские требования: хранение данных учащихся в России, ЕСИА, ФИС ФРДО, чек по 54-ФЗ. Большинство команд видят в этом «плеер плюс база данных» и слишком поздно понимают, что ценность создают отслеживание и стандарты, а не воспроизведение. Эта статья – общая карта курса: для каждого слоя технология, стандарт, российские варианты и типовая ошибка.

Зачем это читать

Если вы директор по обучению, основатель онлайн-школы или продакт и оцениваете проект видеообучения, помните: самые дорогие ошибки случаются до написания кода, когда архитектуру неправильно рисуют на доске. Здесь вся картина собрана в одном месте: что делает каждая часть платформы, какой стандарт к ней относится, что из готового есть на российском рынке и где сосредоточены деньги и риски. Статья намеренно широкая, а не глубокая (каждому слою дальше посвящена отдельная статья): задача – удержать систему в голове и решать «строить или купить» по каждому слою отдельно.

Вся система в одной картинке

Начнём с самого частого заблуждения: платформа видеообучения – это не видеосайт с авторизацией. Онлайн-кинотеатр или архив вебинаров решает одну задачу: надёжно и дёшево доставить картинку на экран. Обучающая платформа должна ещё и знать, кто что посмотрел и понял ли, а потом доказать это проверяющему, HR-системе или деканату. Именно здесь сосредоточены инженерная работа, стандарты и основные затраты. Само видео – самая простая часть.

Платформу удобно представить как сборочную линию. С одного конца поступает сырой учебный материал, с другого выходят подтверждённые результаты обучения. Между ними девять станций, у каждой своя задача, и каждая передаёт работу следующей. Рынок большой, но рост замедляется: по данным Smart Ranking, выручка топ-100 российских EdTech-компаний в 2025 году составила 154 млрд ₽, +12% после +19% в 2024-м и +32% в 2023-м [1]. Когда рынок перестаёт расти сам по себе, правильная архитектура окупается, а ошибки в ней обходятся дорого.

Нажмите, чтобы увеличить

Дальше пройдём по станциям по порядку. Всё, что ниже, – крупный план одной из клеток Рисунка 1.

Слой 1 – Авторинг: где создаются курсы

Авторинг – это превращение знаний в курс: запись или анимация видео, вопросы, структура уроков и упаковка всего этого в формат, который сможет воспроизвести учебная система. Для этого служат средства авторинга – своего рода «текстовые редакторы» e-learning. Одни работают как настольные приложения (самое известное из российских – iSpring Suite), другие встроены в платформу, третьи собирают курс из видеоредактора и отдельного конструктора тестов.

Главное здесь – что получается на выходе, потому что от этого зависит вся цепочка. Курс можно выгрузить самодостаточным пакетом по стандарту, чаще всего по SCORM (Sharable Content Object Reference Model) – старому формату упаковки, который мы разбираем в статье SCORM: что это и когда применять. А можно собрать курс прямо в платформе, чтобы каждое взаимодействие отслеживалось отдельно. От этого выбора зависит, насколько подробно удастся отслеживать обучение: пакет записывает только то, что позволяет его формат, а внутри платформы можно фиксировать каждый клик.

Типовая ошибка – считать авторинг задачей про контент, а не про архитектуру. Команда выбирает инструмент, потому что он нравится методистам, выгружает SCORM-пакет и только потом обнаруживает, что SCORM не умеет записывать посекундные события видео, обещанные в плане по аналитике. Формат выбрали раньше, чем кто-то спросил, какие данные нужны бизнесу.

Слой 2 – Хранилище контента: где лежат файлы

Файлам готового курса – видео, изображениям, тестам, субтитрам, манифестам пакетов – нужно место. Это хранилище контента – обычно S3-совместимое объектное хранилище в российском облаке (Yandex Cloud, VK Cloud, Selectel, Cloud.ru), иногда вместе с базой данных. Более развитый вариант – LCMS (Learning Content Management System): система для версионирования, повторного использования и сборки учебного контента, а не только для хранения файлов.

Две инженерные задачи делают такое хранилище сложнее обычного файлового. Первая – версионирование: если преподаватель исправил ошибку в третьем модуле, те, кто уже проходит курс, не должны незаметно для себя переключиться на новый контент, а старая версия должна остаться доступной для проверки. Вторая – несколько вариантов качества: десятиминутную лекцию хранят не одним файлом, а в нескольких версиях разного качества, чтобы она без рывков шла и по быстрому офисному каналу, и по слабому мобильному. Отсюда прямой переход к следующему слою.

Третья сложность юридическая: рядом с роликами лежат персональные данные – записи занятий с лицами учащихся, их работы, логи просмотров. С 1 июля 2025 года операции с ПДн граждан России в базах за пределами страны запрещены (ч. 5 ст. 18 152-ФЗ) [11], поэтому хранилище, бэкапы и логи размещают в российских дата-центрах.

Типовая ошибка – хранить один огромный файл в высоком разрешении и отдавать его всем. Учащийся с телефона в электричке не вытянет 1080p, видео зависает, и он уходит. В хранилище должны лежать именно те варианты, которые нужны адаптивной доставке.

Слой 3 – Доставка видео: как оно попадает на экран

Этот слой многие принимают за всю платформу. Его задача – без рывков доставить видео из хранилища на экран учащегося, в записи или в прямом эфире. Видео по запросу (VOD) и live устроены совершенно по-разному, и смешивать их – одна из самых частых ошибок при оценке проекта.

Для записанного видео главный приём – адаптивный битрейт (adaptive bitrate): видео кодируют в нескольких вариантах качества, режут на сегменты по несколько секунд, и плеер сам переключает качество в зависимости от канала. Для этого используют два формата – HLS (HTTP Live Streaming) и MPEG-DASH, а сегменты раздаёт CDN (сеть доставки контента) – сеть кэширующих серверов, расположенных ближе к зрителям. Выбор кодеков и «лестницы качества» – отдельная тема, о ней статья выбор видеокодека в 2026.

Весь этот конвейер можно арендовать у видеохостинга, который берёт на себя кодирование, хранение, CDN и плеер: Kinescope (DRM, водяные знаки, API и SDK), Boomstream (DRM, продажа просмотров с фискализацией) или Yandex Cloud Video (CDN, SDK-плеер, трансляции, доступ по токену) [2][3]. VK Видео и Rutube подходят для маркетинговых роликов, но не для закрытого курса с отслеживанием.

Для живых уроков нужна другая техника. Главное требование – низкая задержка: разрыв между словами преподавателя и тем, что слышит учащийся, должен позволять нормально разговаривать, в идеале это меньше нескольких сотен миллисекунд. Обычный стриминг тут не подходит, нужен WebRTC – браузерный стандарт связи в реальном времени, как правило с медиасервером SFU (Selective Forwarding Unit), чтобы выдержать больше нескольких участников. SFU разворачивают из открытого кода (mediasoup, Janus, LiveKit, Jitsi) в российском облаке или берут готовую ВКС – МТС Линк, Яндекс Телемост, TrueConf, Контур.Толк. Школы и колледжи, которые обрабатывают ПДн учеников, обязаны использовать ГИС и мессенджер MAX, куда перенесён «Сферум» (ч. 3.1 ст. 16 273-ФЗ, п. 9 ПП 1678) [7]. Протокол подробно разобран в статье WebRTC для живого обучения.

Нажмите, чтобы увеличить

На доставку приходится и основная часть текущих расходов. Посчитаем: пусть у вас 10 000 активных учащихся, каждый смотрит 5 часов видео в месяц при 3 Мбит/с (нормальное качество 720p).

• 3 Мбит/с – это 0,375 МБ в секунду, пять часов – 18 000 секунд. Один учащийся потребляет 0,375 × 18 000 = 6 750 МБ, то есть около 6,75 ГБ в месяц.
• На 10 000 учащихся это 6,75 × 10 000 = 67 500 ГБ, около 67,5 ТБ в месяц.
• Цена гигабайта в CDN снижается с ростом объёма; ориентировочно это 5–7 ₽ за ГБ (пересчёт типичных тарифов крупных CDN по курсу 85 ₽/$; точную цену сверяйте с прайсом своего провайдера). При средних ≈ 6,3 ₽ за ГБ: 67 500 × 6,3 ≈ 425 000 ₽, то есть около 430 тыс. ₽ в месяц, или примерно 5,1 млн ₽ в год только за трафик, без хранения, транскодинга и живых занятий.

Эта цифра меняет разговор о том, что строить, а что покупать: за весь срок жизни платформы основные деньги часто уходят на доставку, а не на разовую разработку. Поэтому ей посвящены статьи о модели стоимости платформы обучения и о масштабировании доставки. Видеохостинг этот счёт не отменяет: трафик просто входит в его тариф.

Типовая ошибка – считать, что счёт за CDN – единственная статья расходов, или что live и VOD работают на одном конвейере. Живые минуты тарифицируются и проектируются иначе, и если об этом забыть, аккуратный бюджет к концу квартала преподнесёт сюрприз.

Слой 4 – Интерактивный плеер: где просмотр становится обучением

Обучающий плеер – это больше, чем кнопка «играть». Здесь пассивное видео превращается в урок: между фрагментами появляются вопросы, ветвящийся сценарий уводит учащихся по разным путям, заметки и закладки привязаны к моменту на таймлайне, а главы и транскрипт позволяют сразу перейти к нужному месту. Интерактивность – главное, что отличает обучающую платформу от видеохостинга, и именно здесь выводы из статьи о педагогике обучающего видео становятся функциями продукта.

У плеера есть и вторая, незаметная, но не менее важная задача: он служит датчиком для слоя отслеживания. Каждое значимое действие учащегося – запуск, пауза, перемотка назад, ответ на вопрос, завершение фрагмента – рождается здесь как событие. Если плеер его не отправил, ни одна система дальше по цепочке о нём не узнает. Если берёте плеер видеохостинга, сначала проверьте, какие события отдаёт его JavaScript API. Как устроен такой плеер, мы разбираем в статье о создании интерактивного видеоплеера.

Типовая ошибка – выпустить плеер, который отлично воспроизводит видео, но почти ничего не отправляет, а через год подключить аналитику и обнаружить, что данных нет. Анализировать события, которые никто не записывал, невозможно. Решите, что отслеживать, до разработки плеера, а не после.

Слой 5 – Отслеживание: сердце системы

Этот слой отличает обучающие платформы от всего остального, и его же новички недооценивают чаще всего. Задача отслеживания – превращать события плеера в надёжные записи о действиях каждого учащегося, по которым потом можно строить запросы. Для этого есть несколько конкурирующих стандартов, и у каждого свои чёткие границы.

Старейший – SCORM. Когда SCORM-курс запускается в учебной системе, он общается с ней через небольшой JavaScript-интерфейс и записывает фиксированную модель данных: статус завершения, балл, затраченное время и ограниченный набор результатов взаимодействий. Расхожее мнение «SCORM отслеживает всё» неверно: он записывает только этот скромный набор значений и только пока контент работает внутри запустившей его системы. В ходу две версии: SCORM 1.2 (2001) состоит из двух книг спецификации, а в SCORM 2004 4th Edition (2009) добавлены третья книга, Sequencing and Navigation, и раздельные статусы завершения и успешности, так что курс может записать «завершён, но не сдан» как два отдельных факта [4][5]. Для ветвящихся сценариев или более подробного статуса нужен SCORM 2004; для простого «дошёл ли до конца» внутри LMS по-прежнему широко используют 1.2.

Современная альтернатива – xAPI (Experience API); старое рабочее название «Tin Can API» ещё встречается, но стандарт называется xAPI [6]. Единица данных xAPI – утверждение (statement), и проще всего представить его как предложение «актор – глагол – объект», например «Мария – завершила – Модуль 3». Утверждения записываются в LRS (Learning Record Store) – отдельное хранилище со стандартным веб-интерфейсом для приёма утверждений и запросов к ним [6]. Главное преимущество – охват: xAPI фиксирует обучение где угодно – в видео, в симуляции, в мобильном приложении без сети, даже за пределами компьютера, – а не только внутри курса, запущенного из LMS. Для видео сообщество описало xAPI Video Profile – какие именно утверждения отправлять (played, paused, seeked, completed, а также время просмотра и позиция). С ним становится возможной посекундная аналитика просмотра; подробнее – в статье трекинг видео через xAPI.

Между ними стоит cmi5 – спецификация ADL, которая даёт подробное отслеживание xAPI и при этом сохраняет привычную по SCORM схему «LMS запускает курс, курс отчитывается». Это мост между старым и новым подходом. А запуском внешнего инструмента внутри чужой LMS управляет ещё один стандарт – LTI (Learning Tools Interoperability), о нём ниже. Все эти стандарты международные: Moodle, например, поддерживает SCORM 1.2 и LTI 1.3 из коробки, а xAPI и cmi5 – через плагины.

Нажмите, чтобы увеличить

Типовая ошибка – самая дорогая во всей платформе: сделать в видео богатую интерактивность, а отслеживать её голым SCORM, в котором нет понятия «событие видео». Взаимодействия происходят, учащийся их видит, но в записи остаётся только «завершено». Выберите стандарт отслеживания под данные, которые вам действительно нужны, до разработки плеера: плеер и отслеживание – две половины одного решения.

Слой 6 – LMS или LRS: где записи становятся учётной системой

Записи должны храниться в системе, которая ведёт учащихся, курсы, зачисления и результаты. Традиционно это LMS (Learning Management System) – административная основа, которая учитывает, кто на какой курс записан, сроки, обязательное обучение и отчётность. Именно её большинство и представляет, когда слышит «платформа e-learning». В вузах стандарт де-факто – Moodle или собственная ЭИОС (например, SmartLMS в НИУ ВШЭ), в компаниях – iSpring Learn, WebTutor, Mirapolis, Сбер Пульс, в онлайн-школах – GetCourse и похожие платформы. Выбор LMS разобран в статьях построить, купить или расширить LMS и интеграция с российскими LMS и ЭИОС вузов.

Российская особенность: по п. 21 ПП 1678 (ред. ПП 517 от 06.05.2026) LMS, сервисы видеосвязи и прокторинга в составе ДОТ должны соответствовать законодательству РФ и (или) входить в реестр российского ПО [7]. Насколько строга норма с «и (или)», зависит от толкования, но госзаказчики о реестре на закупке спрашивают; iSpring Learn и WebTutor в нём есть.

Рядом с LMS вы услышите ещё несколько аббревиатур, и для оценки проекта их важно различать:

• LXP (Learning Experience Platform) устроена наоборот. LMS управляет администрация (организация назначает курсы), а LXP – сам учащийся: она рекомендует контент, как стриминговый сервис рекомендует сериалы, и нацелена на поиск и вовлечённость, а не на обязательное обучение.
• LCMS (Learning Content Management System), о которой шла речь в разделе о хранилище, занимается созданием, версионированием и повторным использованием контента, а не управлением учащимися.
• LRS из слоя отслеживания – вовсе не полноценная LMS: она только хранит и отдаёт xAPI-утверждения. Во многих современных платформах LRS работает рядом с LMS: LMS ведёт зачисления, LRS собирает подробные данные о взаимодействиях.

Эти аббревиатуры постоянно путают. В таблице – за что отвечает каждая система и какие стандарты поддерживает; последний столбец и определяет объём работ по интеграции.

Типовая ошибка – купить LMS ради каталога курсов и рассчитывать, что она даст подробную аналитику видео. Большинство LMS сами этого не умеют: они записывают завершение и балл, а не посекундную вовлечённость. Из-за этого пробела командам и приходится ставить рядом с LMS свою LRS или отдельный слой аналитики.

Слой 7 – Оценивание и документы: подтвердить результат

Отслеживание фиксирует, что учащийся сделал; оценивание отвечает на вопрос, научился ли он, а документ об обучении делает этот вывод переносимым и проверяемым. Оценивание бывает разным: от вопроса в видео (записанного как SCORM-взаимодействие или xAPI-утверждение) до формального экзамена с прокторингом – этому курс посвящает целый блок. Прокторинг обычно берут готовым – ProctorEdu или Examus. На аттестациях в вузах, колледжах и ДПО учащегося можно идентифицировать через ЕСИА («Госуслуги») и Единую биометрическую систему: сервис прокторинга вправе получить из ЕСИА ФИО и СНИЛС, а для биометрии нужно согласие (п. 14–18 ПП 1678) [7]. Подробности – в статье о подтверждении личности на экзаменах.

Итоговый документ – место, где российская специфика проявляется сильнее всего. Удостоверение о повышении квалификации или диплом о переподготовке выдаёт только организация с лицензией, а сведения о каждом документе вносятся в ФИС ФРДО (ч. 9–10 ст. 98 273-ФЗ) [9]: с 1 сентября 2025 года – в течение 30 дней и со СНИЛС, если он есть (ПП 850) [10]. Формирование документа и выгрузка в ФРДО – часть продукта, а не бухгалтерская формальность.

Поверх документа можно выдавать цифровой знак достижения. Стандарт Open Badges, который развивает 1EdTech, упаковывает достижение вместе с проверяемыми метаданными: кто его выдал и что для него требовалось. Версия важна: Open Badges 3.0 согласован с W3C Verifiable Credentials – более общим стандартом цифровых удостоверений, криптографически защищённых от подделки [8]. Российского регуляторного статуса у них нет: это техническое подтверждение, а не документ об образовании. Подробнее – в статье о сертификатах, значках и верифицируемых удостоверениях.

Типовая ошибка – выдавать «удостоверения» в виде обычных PDF без лицензии и записи в ФИС ФРДО. Такой файл может отредактировать кто угодно, а документ без записи в реестре не пройдёт проверку у работодателя.

Слой 8 – Аналитика: от записей к выводам

В аналитике накопленные записи превращаются в ответы: на каких видео и на какой секунде теряются учащиеся, на каких вопросах ошибаются почти все, какие группы доходят до конца, а какие застревают. Ради этого и ведётся всё отслеживание, но аналитика не бывает лучше событий, которые отправил плеер, и стандарта, по которому они передавались: мусор на входе – мусор на выходе.

Обычно события попадают в LMS или LRS, копируются в хранилище данных (data warehouse) – базу, рассчитанную на аналитические запросы, а не на обслуживание пользователей (часто это ClickHouse в российском облаке), – и выводятся на дашборды. Зарубежные системы аналитики для данных конкретных учащихся не подходят: действует та же ч. 5 ст. 18 152-ФЗ [11]. Особенность, присущая именно обучению, – в определениях. «Завершение» можно понимать по-разному: «дошёл до конца видео», «посмотрел 90% длительности» или «верно ответил на итоговый вопрос», и на одних и тех же данных это даёт очень разные цифры. Статья аналитика обучения построена как раз вокруг таких ловушек.

Типовая ошибка – цепочка «посмотрел 100% = завершил = научился», где за каждым знаком равенства скрыто ложное допущение. Учащийся может оставить видео в фоновой вкладке (100% «просмотра»), ни во что не вникнуть (завершения по существу нет) и уж точно ничему не научиться. Задайте точное определение каждой метрики, иначе дашборд будет уверенно показывать то, чего нет.

Слой 9 – Отчётность и интеграция: замкнуть цикл

Последняя станция передаёт результаты туда, где они нужны: на дашборд руководителя, в ЭИОС вуза, в корпоративную HR-систему, а в охране труда – в реестр обученных лиц ЕИСОТ Минтруда (сведения вносятся в течение трёх рабочих дней после проверки знаний, ПП 2464) [14]. Интеграция опирается на те же стандарты: SCORM и cmi5, xAPI с передачей во внешнюю LRS и LTI для запуска инструментов с передачей оценок. Корпоративная сторона разобрана в статье интеграция с корпоративными LMS и HR-системами.

LTI стоит описать точно, потому что его часто понимают неправильно. Learning Tools Interoperability – стандарт 1EdTech (бывший IMS Global), который позволяет запускать ваш видеоинструмент внутри чужой LMS – Moodle, ЭИОС вуза, корпоративной системы – на правах доверенного гостя. Текущая версия, LTI 1.3 с сервисами LTI Advantage, делает это через защищённый обмен на базе OpenID Connect с подписанным токеном (JWT), а не через общий пароль; единый вход (SSO) – следствие этого обмена, а не его суть [12][13]. LTI Advantage добавляет три сервиса, важных для видеоинструмента: Deep Linking (преподаватель выбирает конкретный материал для вставки в курс), Names and Role Provisioning Services (инструмент получает список группы) и Assignment and Grade Services (результаты автоматически попадают в журнал оценок LMS) [12][13]. Подробно всё это разобрано в статье LTI: запуск инструментов внутри любой LMS.

Типовая ошибка – описывать LTI как «вход пользователя». Это подталкивает команды строить хрупкую связку на паролях вместо стандартного протокола запуска. Если реализовать механизм правильно, интеграция будет защищённой и воспроизводимой; если нет – подключение каждой новой LMS превращается в отдельный хрупкий проект.

Слой поверх всех: стандарты, доступность и требования РФ

Десятый слой на Рисунке 1 – не станция: он охватывает все девять. Стандарты мы уже встречали – SCORM, xAPI, cmi5, LTI, Open Badges, Verifiable Credentials, – и правило для всех одно: указывайте стандарт вместе с версией. «Поддерживаем SCORM» без номера версии со временем превращается в реализацию, которая стандарту не соответствует.

О доступности команды чаще всего вспоминают слишком поздно – когда о ней спрашивают на закупке. Технический ориентир – WCAG 2.1 уровня AA (W3C, 2018) [15] и основанный на нём ГОСТ Р 52872-2019 [16]. Стандарт добровольный, но его прописывают в ТЗ, а 273-ФЗ требует создавать специальные условия для обучающихся с ОВЗ, вплоть до услуг сурдопереводчика (ст. 79) [17]. Для обучающего видео главное – критерии 1.2.2 «Субтитры (в записи)», 1.2.4 «Субтитры (в прямом эфире)» и 1.2.5 «Аудиодескрипция»: субтитры в записанных роликах, субтитры на живых уроках и описание изображения для тех, кто не видит экран. Полный разбор – в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео.

Третья часть сквозного слоя – российские требования, которые затрагивают сразу несколько станций. Их удобнее свести в таблицу.

Две строки требуют пояснений. Вход: с 1 декабря 2023 года российские сайты авторизуют пользователей из России только по российскому номеру телефона, через ЕСИА, ЕБС или информационную систему российского юрлица [18]. Платежи: чек выдаётся в момент онлайн-расчёта – через облачную кассу агрегатора или собственную ККТ с ОФД (54-ФЗ) [19]; проще всего, когда фискализацию берёт на себя платёжный провайдер.

Типовая ошибка – отгрузить каталог без субтитров заказчику, у которого в ТЗ записан ГОСТ Р 52872-2019, или собрать MVP на зарубежных сервисах форм и аналитики, а потом переезжать в разгар продаж. И то и другое дешевле заложить в проект сразу, чем переделывать потом.

Как слои распределяются между «строить» и «купить»

Практический смысл карты в том, что вы принимаете не одно решение «строить или купить», а девять – по одному на слой, и они связаны между собой. Часть слоёв – типовые блоки, которые почти всегда выгоднее купить или арендовать (доставка видео, объектное хранилище, платёжный шлюз). Часть – то, чем продукт отличается от конкурентов: такие слои серьёзные команды обычно разрабатывают сами (интерактивный плеер, определения аналитики). Остальное – стыки, где правила задаёт стандарт или госсистема, а не ваш код (LTI, SCORM/cmi5, ЕСИА, ФИС ФРДО): здесь нужно соответствовать, а не изобретать.

Нажмите, чтобы увеличить

На практике удобно пройти Рисунок 1 слева направо и пометить каждую клетку. Авторинг: купить инструмент, если ваша модель контента не слишком необычна. Хранилище и доставка: арендовать у российского облака или видеохостинга. Интерактивный плеер: это и есть ваш продукт – разрабатывать самим или взять расширяемый компонент. Отслеживание: реализовать стандарт, который подходит под ваши данные. LMS/LRS: расширить существующую (часто Moodle) или поставить LRS рядом с купленной LMS. Оценивание: прокторинг купить, документы выдавать по лицензии с выгрузкой в ФИС ФРДО. Аналитика: определения метрик делать своими, даже если сам конвейер куплен. Отчётность: поддержать LTI и государственные реестры, которые вас касаются. Подробнее – в статье построить, купить или расширить LMS.

Все ошибки в одной таблице

Соберём все типовые ошибки в один список: по нему удобно проверить любую предлагаемую архитектуру ещё до старта.

Где здесь Фора Софт

Фора Софт разрабатывает видеософт с 2005 года: e-learning, видеоконференции, стриминг, OTT, видеонаблюдение и телемедицина, более 250 выпущенных проектов. Мы начинаем с этой карты, потому что с командами из сферы обучения разговор почти никогда не сводится к вопросу «умеете ли вы стримить видео» – это умеет большинство инструментов. Вопрос в другом: какие из девяти слоёв вы разрабатываете, какие покупаете, а где следуете стандарту. Если распределить это правильно с самого начала, вы не потратите бюджет на разработку типовых блоков и не сэкономите на интерактивном плеере, который и есть ваш продукт. Наш опыт как раз на стыке видеосвязи в реальном времени, стриминга, интерактива и отслеживания, которые превращают видео в обучение, – это самая сложная и ценная середина схемы. Инфраструктуру мы разворачиваем в российских облаках, а видеохостинги, ВКС, платёжные шлюзы и ЕСИА подключаем готовыми блоками.

Главное

• Обучающая платформа – это девять слоёв, а не плеер с авторизацией.
• Ценность и затраты сосредоточены в отслеживании и стандартах, а не в воспроизведении.
• Выберите стандарт отслеживания под нужные данные до разработки плеера.
• SCORM записывает фиксированную модель; xAPI – что угодно, включая события видео.
• «Строить или купить» решается по каждому слою, а не для всей системы сразу.
• Данные учащихся – в России, документы – в ФИС ФРДО, оплата – с чеком по 54-ФЗ: закладывайте это в архитектуру сразу, как и доступность.

Что читать дальше

• SCORM: что это, что отслеживает и когда применять
• Интеграция с российскими LMS и ЭИОС вузов
• Модель стоимости платформы обучения: во что обходится создание и эксплуатация