GetCourse, iSpring или своя LMS: когда онлайн-школе нужна отдельная платформа

Каждую пятницу кто-то в онлайн-школе открывает большую таблицу. Уроки приезжают в неё из LMS, оплаты — из CRM, посещаемость — из сервиса видеосвязи, переносы — из чатов. К вечеру цифры сходятся. Через неделю всё сначала.

Для ученика школа пока выглядит цельно. Сотрудники уже соединяют несколько систем и помнят, где чаще всего расходятся данные.

Привет, я Антон Фокин, CEO Qtim. Мы разрабатываем EdTech-продукты и часто подключаемся именно в такой момент: готовая LMS работает, но каждое изменение требует ещё одной выгрузки, интеграции или инструкции для команды. Тогда выбор платформы сводится к двум вопросам: какой процесс перестал помещаться в готовой системе и сколько школа уже платит за обходы.

Сначала найдите место, где школа начинает скрипеть

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

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

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

GetCourse хорош, пока путь ученика умещается в одну воронку

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

Стандартный путь ученика укладывается в понятную цепочку: заявка, оплата, группа, уроки, задания и сообщения. Команда работает в одной системе и быстрее проверяет новые продукты. На этом этапе собственная LMS обычно отвлекает деньги и людей от методики, продаж и контента.

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

iSpring держит учебный контур, а продажи живут по соседству

iSpring LMS подходит проектам, где центр тяжести находится в учебных материалах и управлении обучением. В платформу можно загружать SCORM-курсы, создавать тесты и лонгриды, назначать программы группам, собирать отчёты и давать доступ к материалам через мобильное приложение, в том числе без интернета. Через API и готовые интеграции учебный портал связывается с другими системами.

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

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

Своя LMS начинается там, где методику приходится объяснять платформе

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

Между SaaS-платформой и разработкой с нуля есть open-source LMS, например Moodle. Готовое ядро подходит, если базовая логика курсов устраивает школу, а команда или подрядчик берёт на себя хостинг, обновления, безопасность, плагины и интеграции. Глубокие доработки переносят часть учебной логики в плагины и форки, поэтому расходы на разработку и поддержку остаются, как и зависимость от технической команды.

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

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

Пять признаков, что LMS уже управляет школой

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

Методисты сначала проектируют сильную программу, затем обрезают её до доступных блоков. Полезный сценарий не попадает в продукт, потому что его трудно собрать из модулей, уроков и тестов. Со временем школа конкурирует контентом внутри той же механики, что и другие проекты.

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

Живой урок существует отдельно от учебной истории. Ссылка на внешнюю встречу работает, пока достаточно провести занятие. Когда школе нужны автоматические записи, посещаемость, права на подключение и связь активности с прогрессом, видеосвязь становится частью образовательного контура.

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

Один симптом редко оправдывает разработку. Повторяющиеся проблемы уже требуют аудита процессов, данных и связей между системами.

У «Стадикэтс» было шесть курсов и ни одного общего кабинета

До отдельной платформы у «Стадикэтс» было шесть самостоятельных курсов по подготовке к ЕГЭ и ОГЭ. У каждого направления были свои страницы, тарифы и формат проверки. Ученик собирал подготовку как маршрут по нескольким продуктам, а у команды не было общего центра управления и сквозной статистики.

В новой системе появились общий личный кабинет, расписание, домашние задания, пробники, карточки для повторения и геймификация. Платформа связала путь ученика по разным предметам и дала команде одни правила проверки и управления курсами. От старта до релиза прошло 5 месяцев; на запуске в системе занимались 1000+ учеников.

Пики перед дедлайнами потребовали отдельного архитектурного решения. Когда ученики массово присылают домашние задания и аудиозаписи, обработка файлов может задержать основной кабинет. Такие операции вынесли в фон через BullMQ и очереди на Redis: платформа фиксирует сдачу, ученик продолжает заниматься, а отдельный процесс обрабатывает файл и обновляет статус.

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

В «Онлайн-школе №1» права доступа разделили на 18 ролей

В «Онлайн-школе №1» основной учебный путь работает в вебе: расписание, задания, материалы, проверки, календарь и инструменты преподавателей. В системе 18 ролей, среди них учителя, кураторы, координаторы и администраторы. Для каждой настраиваются доступные блоки и действия; новую роль можно добавить без переписывания всей модели доступа.

По мере развития вокруг ядра появились отдельные продукты. Собственная ВКС связала уроки с расписанием, авторизацией, записями и управлением участниками. Мобильный дневник закрыл другой сценарий: родитель видит расписание, оценки, посещаемость и задания нескольких детей. Учебное ядро при этом осталось в вебе.

Автоматизация охватила около 80% проверок и освободила примерно 25 часов команды в неделю, которые раньше уходили на проверку домашних заданий. В опубликованных результатах проекта конверсия в оплату дополнительных курсов выросла с 12% до 27%, а удержание — с 48% до 64%.

Разные пользовательские маршруты опираются на общую модель данных. Ученика, учителя, куратора и родителя развели по интерфейсам с конкретными задачами, а общий серверный контур синхронизирует расписание, статусы, оценки и права.

Релиз прошёл, а счёт за LMS остался

После релиза разработка продолжается. Браузеры и мобильные системы обновляются, интеграции меняют API, растёт объём данных, появляются новые роли и требования к защите информации. Нужны мониторинг, резервное копирование, тестирование и команда, которая принимает продуктовые решения.

Опубликованные кейсы дают ориентир по срокам: первый релиз платформы «Онлайн-школы №1» занял 3 месяца, объединение шести курсов «Стадикэтс» — 5 месяцев. Для отдельной LMS это горизонт в несколько месяцев. Планировать такой проект как двухнедельный спринт слишком оптимистично. Точная смета зависит от состава ролей, объёма миграции, количества интеграций, живых занятий, мобильных сценариев, требований к нагрузке и состава команды.

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

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

Переезд начинают с истории ученика

Переход на отдельную платформу начинается с процессов и данных. Команда фиксирует, где хранятся пользователи, группы, оплаты, прогресс, оценки, задания, записи занятий и права доступа. Затем определяет, какая история нужна в новом контуре с первого дня.

Дальше двигаемся поэтапно:

1. описать основной путь ученика и действия сотрудников;
2. собрать карту данных и интеграций;
3. перенести один законченный сценарий, например курс или поток;
4. проверить его на ограниченной группе;
5. сверить доступы, оплаты и прогресс до переключения остальных пользователей.

Самый чувствительный участок — продолжение обучения после миграции. Ученик должен открыть нужный урок, увидеть сданные работы и сохранить доступ по своему тарифу. Пилот на реальном потоке проверяет данные, роли и интеграции в одном маршруте. Скучная сверка до запуска заметно приятнее эффектного письма «мы уже всё починили» после него.

Своя платформа нужна, когда коробка редактирует методику

GetCourse разумно выбирать для быстрого запуска школы и связки обучения с продажами. iSpring подходит, когда основная задача — создавать программы, назначать их группам и контролировать результаты. Собственная LMS оправдана, когда методика, роли, живые занятия, интеграции и поведение системы под нагрузкой определяют качество образовательного продукта.

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

Если несколько признаков из статьи совпали, команда Qtim может провести аудит текущего контура. Мы разделим задачи на настройки готовой LMS, интеграции и продуктовую разработку, а затем соберём состав следующего релиза. Подробнее — на странице EdTech-разработки Qtim.