Платформы для цифрового обучения: подбор под разные задачи

Цифровое обучение на онлайн-платформах — это не выбор между «красивым интерфейсом» и «не очень красивым». Это выбор архитектуры, модели владения данными, набора интеграций и глубины аналитики. Ошибка здесь редко выглядит драматично в день запуска. Она проявляется через год: контент нельзя перенести, отчёт по обязательному обучению собирают вручную, мобильный тренажёр не передаёт события в LMS, а стоимость одного активного пользователя вдруг превышает стоимость самого курса.

На российском рынке корпоративных LMS около 80% сегмента делят пять разработчиков: iSpring, WebSoft, Mirapolis, «Эквио» и Teachbase. Это не означает, что у пяти систем одинаковый стек или одинаковая экономика. Означает другое: рынок уже достаточно зрелый, чтобы не покупать платформу по демо на 40 минут.

Облако или собственный контур: архитектура раньше интерфейса

Первый вопрос при выборе платформы для онлайн-обучения — не «есть ли геймификация». Первый вопрос: где будет жить система и учебные данные.

Есть две базовые модели: SaaS и On-Premise. В облачной модели поставщик держит инфраструктуру, выпускает обновления, отвечает за доступность сервиса, резервное копирование и значительную часть операционной безопасности. В серверной установке система размещается в инфраструктуре заказчика: на собственных серверах или в его закрытом контуре.

Разница не академическая. Она определяет бюджет, скорость запуска, требования к команде и пределы кастомизации.

SaaS выбирают не потому, что «облако модно». Его выбирают, когда компании нужно начать обучение в квартале, а не превратить LMS в двухлетний IT-проект. Для отдела продаж, сети филиалов, онбординга или регулярной сертификации это часто рациональный маршрут. Поставщик берёт на себя слой, который бизнес обычно недооценивает: обновления, масштабирование, мониторинг, резервные копии, совместимость браузеров.

У этой рентабельности есть цена. Заказчик зависит от продуктового бэклога вендора. Если нужная функция не попала в план разработки, аргумент «нам очень надо» редко меняет ситуацию. Если требуется нестандартная ролевая модель, особая логика согласований или глубокая интеграция с внутренними системами, облачная платформа быстро упирается в границы тарифа и API.

On-Premise выглядит как контроль. Иногда им и является. Особенно если данные об обучении, кадровые сведения и результаты аттестации не должны выходить за пределы закрытого контура. Но собственное размещение не отменяет расходы, а переносит их в другие статьи: серверы, администрирование, обновления, резервное копирование, мониторинг, устранение инцидентов.

Бесплатная лицензия Moodle — классический пример ловушки входной цены. Сам продукт распространяется бесплатно. Проект при этом не становится бесплатным: нужен сервер, специалист по администрированию, настройка ролей, шаблонов курсов, интеграций, поддержка пользователей. В крупной организации эта схема может быть оправдана. В компании на несколько сотен учащихся она нередко превращает «экономию» в ручную сборку без гарантий сроков.

Бесплатная LMS — не нулевая стоимость. Это счёт, в котором часть строк просто выписана не поставщиком, а вашей IT-службой.

Стандарты: где заканчивается SCORM и начинаются данные

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

Для базового корпоративного обучения рынок десятилетиями держится на SCORM. Первая версия стандарта вышла ещё в 2000 году, и он по-прежнему остаётся самым распространённым форматом упаковки электронных курсов. Не потому, что индустрия не слышала про новые технологии. Потому что SCORM закрывает массовый сценарий: загрузить курс в LMS, назначить группе, отследить запуск, прогресс, результат теста и факт завершения.

SCORM хорошо работает для обязательных программ: охрана труда, информационная безопасность, адаптация, регламенты, сертификация. Его слабое место — рамка браузера и LMS. Стандарт ориентирован на прохождение учебного модуля в системе, причём контент обычно размещается на одном сервере с платформой. Для видео, слайдов и тестов этого достаточно. Для реальной картины обучения — уже нет.

xAPI, также известный как Tin Can API, решает другую задачу. Он фиксирует учебные события не только внутри LMS. Пользователь может пройти тренажёр в мобильном приложении, отработать сценарий в симуляторе, выполнить действие в VR-среде, а система отправит событие в Learning Record Store — LRS, специальное хранилище учебных записей.

Логика xAPI строится вокруг простого формата: кто-то совершил действие с чем-то. Не «сотрудник завершил курс», а «сотрудник выполнил упражнение», «посмотрел фрагмент», «ошибся в сценарии», «повторил модуль», «сдал попытку». Разница существенная. Первая метрика говорит, что курс был открыт. Вторая показывает поведение.

cmi5 появился в июне 2016 года как попытка соединить управляемость SCORM с гибкостью xAPI. Он задаёт более строгую рамку запуска курсов из LMS, но допускает внешний хостинг контента и офлайн-сценарии. Для компании это означает меньше компромиссов, если обучение выходит за пределы одного браузерного окна, но всё ещё требует централизованного назначения и контроля.

Отдельно стоит LTI — Learning Tools Interoperability. Это не формат упаковки курса и не конкурент SCORM. LTI нужен для интеграции внешних учебных инструментов: виртуальных лабораторий, систем тестирования, сервисов видеосвязи, библиотек заданий, симуляторов. Когда LMS становится не единственным продуктом, а точкой входа в экосистему, LTI снижает объём самописных стыковок.

Типовая ошибка закупки выглядит так: компания просит поддержку SCORM, получает галочку в коммерческом предложении и считает вопрос закрытым. Затем появляется мобильный курс для полевых сотрудников, VR-тренажёр для техники безопасности или внешний сервис оценки навыков. И выясняется, что «поддержка xAPI» означает импорт одного формата, но не включает LRS, не даёт готовых отчётов и не позволяет собрать данные из нескольких источников.

Поддержка стандарта — не бинарная характеристика. Вопрос нужно формулировать жёстче:

• какие именно события система принимает и хранит;
• есть ли встроенный LRS или потребуется отдельное хранилище;
• можно ли выгрузить сырые данные, а не только смотреть преднастроенный дашборд;
• как система ведёт себя при нестабильном интернете и офлайн-прохождении;
• кто отвечает за настройку пакетов, если курс собран внешним подрядчиком;
• что происходит при переносе контента в другую LMS.

Последний пункт особенно неприятен для маркетинга поставщика. Поэтому его и нужно задавать первым.

Роли в LMS: три сущности, которые определяют хаос

В классической LMS есть три базовые роли: учащийся, автор и администратор. На слайде это выглядит как банальность. В реальном проекте именно распределение прав определяет, будет ли обучение управляемым или превратится в папку с файлами и двадцать Excel-таблиц.

Учащийся проходит назначенные программы, получает уведомления, видит сроки и результаты. Это самая заметная роль, но не самая сложная.

Автор управляет учебными материалами: собирает курсы, обновляет модули, настраивает тесты, иногда — траектории и правила выдачи сертификатов. Здесь нужно отделять две функции, которые многие платформы и компании смешивают: создание контента и публикацию контента. Методист может иметь право собирать курс, но не выпускать его на 10 тысяч пользователей без проверки. Если в LMS нет такого разграничения, контроль качества держится на дисциплине. Дисциплина плохо масштабируется.

Администратор управляет пользователями, группами, ролями, назначениями, доступами и частью отчётности. В крупной структуре это не один человек, а несколько уровней: центральный администратор, региональный координатор, руководитель подразделения. Если все получают полные права «чтобы не тормозить процесс», через полгода никто не понимает, кто удалил группу, поменял срок курса или выдал доступ подрядчику.

Для дистанционного обучения онлайн-платформы должны отвечать не только на вопрос «как загрузить курс», но и на вопрос «кто может изменить учебный процесс». Нормальная ролевая модель включает:

1. Раздельные права на контент и аудиторию. Автор редактирует модуль, но не должен автоматически видеть кадровые данные всех сотрудников.

2. Группы и оргструктуру. Назначение по филиалу, должности, подразделению или этапу адаптации должно работать без ручного выбора сотен фамилий.

3. Правила автоматизации. Новый сотрудник попадает в группу — получает стартовую траекторию. Срок сертификата истёк — программа назначается повторно. Это не магия. Это базовая экономия операционных часов.

4. Аудит действий. Для обязательного обучения нужен след: кто назначил курс, когда изменил результат, по какой причине выдано исключение.

5. Разные контуры отчётности. Руководителю нужна картина по команде. Методисту — сложные вопросы и точки отвалов. Администратору — доступы и статусы. Один универсальный отчёт не закрывает все три задачи.

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

LMS без дисциплины ролей — это не система обучения. Это общий диск с логином.

Экономика: тариф — только первая строка сметы

На витрине цены выглядят просто. iSpring Learn предлагает тарифы от 158 рублей за пользователя в месяц. У GetCourse стартовая цена — от 5900 рублей в месяц. Moodle можно получить без лицензионной платы. Из этих трёх фраз невозможно выбрать платформу. Зато ими легко создать ложное ощущение дешёвого проекта.

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

В смете обычно есть как минимум пять слоёв:

• Лицензия или подписка. Может считаться по зарегистрированным, активным или одновременно обучающимся пользователям. Эти модели дают разную цифру при одной и той же базе сотрудников.
• Внедрение. Перенос пользователей, настройка оргструктуры, ролей, уведомлений, шаблонов, каталогов и отчётов.
• Интеграции. Кадровая система, SSO, корпоративный портал, CRM, сервисы вебинаров, BI. Чем больше ручных выгрузок, тем дороже обходится якобы дешёвая LMS.
• Контент. Готовые SCORM-курсы, разработка тестов, запись видео, обновление нормативных программ, локализация материалов.
• Поддержка и администрирование. В SaaS она частично включена в продукт. В On-Premise становится постоянной задачей IT и внутреннего L&D-контура.

Стандартный пробный период у облачных LMS часто составляет 14 дней. Этого достаточно, чтобы проверить интерфейс и загрузить тестовый пакет. Этого недостаточно, чтобы оценить систему. За две недели нужно успеть не «покликать меню», а воспроизвести один реальный бизнес-сценарий.

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

Если демо проходит на шаблонном курсе с тремя пользователями, проверяется интерфейс. Если проходит на своём процессе, проверяется продукт.

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

Рынок: выбирать надо не лидера, а класс задачи

Пять крупнейших игроков — iSpring, WebSoft, Mirapolis, «Эквио» и Teachbase — занимают около 80% российского рынка корпоративных платформ. Концентрация высокая. Но формулировка «лидер рынка» для выбора почти бесполезна.

Лидер удобен для презентации закупочному комитету. Для проекта важнее другое: подходит ли продукт под конкретную модель обучения, структуру пользователей, требования к данным и стек интеграций.

Есть несколько типовых классов задач.

Массовое обязательное обучение

Это комплаенс, охрана труда, вводные программы, внутренние регламенты, продуктовые знания. Нужны стабильный SCORM, массовые назначения, контроль сроков, тестирование, сертификаты, отчётность. Сложная xAPI-аналитика здесь может быть полезна, но не является ядром проекта.

Главная метрика — не число опубликованных курсов. Это доля сотрудников, завершивших назначенную программу в срок, и стоимость администрирования этого процесса.

Онбординг и развитие сотрудников

Здесь важнее траектории, сегментация по ролям, связка с оргструктурой, повторные назначения и работа руководителя с прогрессом команды. Контент может быть смешанным: SCORM, видео, вебинары, задания, очные активности.

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

Академия партнёров и клиентов

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

GetCourse часто рассматривают именно в логике запуска и продажи образовательных продуктов. Но тариф от 5900 рублей в месяц сам по себе не отвечает на вопрос, подходит ли система корпоративному университету со сложной оргструктурой и внутренним контуром данных. Разные классы продукта. Одинаковое слово «платформа» сбивает с толку.

Симуляторы, мобильное обучение и VR

Это зона xAPI и LRS. Если обучение происходит не только в веб-курсе, нужно заранее определить, какие данные будут собираться и кто их будет читать. Иначе компания инвестирует в интерактивный тренажёр, а в финальном отчёте снова видит только «прошёл / не прошёл».

Для таких проектов выбор платформы для онлайн-обучения надо начинать не с каталога курсов, а со схемы событий: какие действия пользователя имеют значение, где они возникают, куда записываются, как связываются с профилем сотрудника и какие решения принимаются на основе этих данных.

Вердикт: платформа не исправляет слабый учебный процесс

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

SaaS рационален для быстрого старта и типовых корпоративных процессов. On-Premise нужен там, где закрытый контур и глубокая адаптация важнее скорости. SCORM остаётся рабочей базой для массовых курсов. xAPI и cmi5 нужны не «на вырост», а когда обучение действительно выходит в мобильные приложения, симуляторы и другие внешние среды. LTI становится полезным, когда LMS перестаёт быть единственным инструментом.

Итоговая развилка выглядит без романтики:

Покупать стоит не «лучшую LMS на рынке». Такой категории нет. Есть платформа, которая закрывает измеримый сценарий с понятной стоимостью эксплуатации. Всё, что не укладывается в эту формулу, — презентация отдела продаж.