Не просто онлайн-курсы: как мы перенесли «Траекторию» РУК из ручного процесса в цифровую LMS

У Российского университета кооперации уже существовал работающий образовательный продукт — курс «Траектория». Проблема была не в содержании курса, а в том, как человек его покупал, проходил, подтверждал оплату и получал документы. Значительная часть процесса держалась на сотрудниках филиалов, ручном переносе данных и взаимодействии с 1С. Наша задача заключалась не в том, чтобы выложить уроки в интернет. Нужно было собрать полноценную цифровую систему: от регистрации и оформления договора до прохождения курса, контроля прогресса и получения сертификата.

«Траектория» была не просто подготовительным курсом

Чтобы понять масштаб задачи, важно сначала разобраться в самом процессе.

«Траектория» помогала будущим абитуриентам подготовиться к поступлению и получить дополнительные знания. Но её роль не ограничивалась обучением.

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

Иными словами, человек покупал не просто набор уроков. Он входил в более длинный маршрут:

• Выбирал и приобретал курс
• Передавал данные для оформления
• Посещал занятия и проходил программу
• Получал сертификат
• Предоставлял его при поступлении
• Продолжал взаимодействие с университетом уже как абитуриент

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

Это делало «Траекторию» не обычным инфопродуктом, а частью реального образовательного и договорного процесса.

Мы цифровизировали не видеоуроки. Мы цифровизировали путь человека к обучению в университете.

PANTELIDI

Рабочий процесс существовал, но держался на ручных действиях

До запуска новой платформы значительная часть процесса оставалась физической.

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

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

Кто-то должен проверить данные.

Кто-то должен вручную добавить человека.

Кто-то должен убедиться, что оплата прошла.

Кто-то должен объяснить пользователю, почему доступ ещё не появился.

Кто-то должен найти договор, подтвердить обучение и подготовить итоговый документ.

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

Ручная система создавала нагрузку сразу на всех.

Студент ждал и нервничал.

Сотрудник филиала выполнял повторяющиеся операции.

Администрация собирала сведения из разных источников.

Развитие новых программ означало ещё больше ручной работы.

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

Вместо страницы одного курса мы сразу заложили масштабируемую LMS

Самым простым решением было бы сделать отдельный лендинг «Траектории», добавить форму регистрации, кнопку оплаты и закрытый раздел с уроками.

Но тогда при появлении следующей программы пришлось бы снова создавать отдельный сайт или переделывать существующую систему.

Мы сознательно пошли другим путём.

Вместо площадки для одного курса была спроектирована полноценная LMS — система, в которой можно создавать, публиковать, проходить и администрировать разные образовательные программы.

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

Это решение почти сразу подтвердило свою пользу. Одновременно с запуском портала на нём разместили не только «Траекторию», но и программы подготовки к ЕГЭ и ОГЭ по информатике и истории.

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

• Каталог опубликованных программ
• Отдельная страница каждого курса
• Разные стоимости для филиалов
• Управление видимостью и публикацией
• Категории и теги
• Продолжительность и формат обучения
• Описание результата программы
• Возможность добавлять новые курсы без переделки системы

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

Наблюдение из практики

Регистрация должна была выдерживать реальную жизнь

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

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

Кто-то забывает пароль.

Кто-то ошибается в адресе электронной почты.

Кому-то не приходит письмо.

Кто-то закрывает страницу и возвращается позже.

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

Мы проработали не только идеальный сценарий, но и ситуации, которые обычно возникают после запуска.

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

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

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

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

Для несовершеннолетних был предусмотрен отдельный договорный маршрут. Система определяла возраст слушателя и при необходимости запрашивала данные заказчика — родителя или ответственного взрослого.

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

Оплата и 1С должны были работать как один понятный процесс

Платёжная часть не создавалась в отрыве от существующей инфраструктуры университета.

Эквайринг и фиксация оплаты уже работали на стороне РУК. После проведения платежа информация сохранялась во внутренней системе и 1С. Наша платформа должна была корректно встроиться в этот процесс.

При оформлении «Траектории» портал собирал необходимые данные слушателя и, если требовалось, заказчика. Информация передавалась во внешний сервис РУК для создания договора.

В ответ система получала номер договора и ссылку на оплату.

После оплаты платформа обращалась к отдельному сервису и проверяла её статус. Доступ к обучению открывался только после подтверждения со стороны внутренней системы университета.

Это принципиально важная деталь.

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

Поэтому источником истины оставалась система РУК.

• Пользователь заполняет данные
• Система учитывает филиал и статус заказчика
• Во внешней системе создаётся договор
• Пользователь получает ссылку на оплату
• Оплата фиксируется на стороне РУК и в 1С
• Портал проверяет её через интеграционный метод
• После подтверждения открывается доступ к обучению
• Договор и статус появляются в личном кабинете

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

В платёжном сценарии интерфейс должен не только принимать деньги. Он должен объяснять, что происходит после нажатия кнопки.

PANTELIDI

Личный кабинет собрал обучение, данные и документы в одном месте

После регистрации и оплаты пользователь попадал в личный кабинет.

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

Какие курсы мне доступны?

Сколько уже пройдено?

Где продолжить обучение?

Какие программы ещё можно выбрать?

Где лежит договор?

Где скачать сертификат?

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

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

На странице «Мои курсы» отображались активные и завершённые программы. У каждой карточки был прогресс, по которому человек сразу видел, сколько материала уже пройдено.

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

Страница «Все курсы» открывала общий каталог, а раздел «Мои документы» собирал договор и полученные сертификаты.

• Профиль и редактирование личных данных
• Активные курсы
• Завершённые курсы
• Прогресс прохождения
• Другие доступные программы
• Общий каталог
• Договор по «Траектории»
• Сертификаты о прохождении

Курс-вьюер был разработан под реальный образовательный сценарий

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

Мы не использовали готовый универсальный плеер и не пытались подогнать программу под ограничения сторонней LMS. Структура курса, уроки, внутренние блоки и навигация были разработаны специально под задачи заказчика.

Курс разбивался на модули, модули — на уроки, а уроки — на отдельные контентные блоки.

Внутри одной программы можно было сочетать разные форматы:

• Текстовые уроки
• Видеоматериалы
• Тесты
• Внешние ссылки
• Прикреплённые ресурсы
• Дополнительные материалы
• Последовательные модули и уроки

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

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

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

Это превращало набор материалов в управляемый образовательный маршрут.

Тесты, попытки и сертификаты работали внутри одной логики

Тестирование было встроено непосредственно в структуру уроков.

Преподаватель мог создать тест, добавить вопросы и варианты ответов, настроить ограничение по количеству попыток и при необходимости перемешивание вопросов.

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

После проверки варианты блокировались, чтобы результат попытки не изменялся задним числом.

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

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

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

Для «Траектории» этот документ был особенно важен, потому что связывал онлайн-обучение с дальнейшим маршрутом поступления.

Хорошая LMS должна помнить не только то, что человек открыл урок. Она должна понимать, что он действительно прошёл.

Наблюдение из практики

Для преподавателей мы создали собственный конструктор курсов

Платформа должна была быть удобной не только для слушателей.

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

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

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

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

Конструктор работал не как одно большое поле редактирования, а как последовательная система связанных сущностей:

• Основные данные курса
• Модули
• Уроки
• Контентные блоки
• Ссылки и дополнительные ресурсы
• Тесты
• Вопросы и варианты ответов
• Публикация и управление доступностью

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

Это была не стандартная административная форма Django, выданная преподавателю без адаптации. Поверх внутренней модели был разработан отдельный интерфейс, соответствующий реальному процессу создания образовательного контента.

Администрация получила не только контент, но и картину происходящего

Отдельный слой платформы предназначался для контроля работы системы.

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

Также отображались наиболее востребованные курсы и общая статистика использования платформы.

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

Это важное отличие от старого процесса.

Раньше сотрудники вручную вносили сведения в систему и фактически сами создавали цифровой след каждого действия.

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

• Количество пользователей
• Записи на курсы
• Активные и завершённые прохождения
• Популярные программы
• Договоры по «Траектории»
• Подтверждённые оплаты
• Выданные сертификаты
• Выгрузка данных для дальнейшей обработки

Результат: из сложного процесса получился самостоятельный образовательный продукт

На старте была одна конкретная проблема: перевести покупку и прохождение «Траектории» из преимущественно ручного процесса в цифровой.

На выходе получилась полноценная LMS.

Она не ограничилась оплатой одного курса и не стала электронной копией прежнего процесса. Платформа связала в одной системе каталог, филиалы, регистрацию, подтверждение email, договоры, 1С, оплату, личный кабинет, обучение, тестирование, прогресс, сертификаты и административную статистику.

Для слушателя путь стал понятнее.

Для преподавателя — управляемее.

Для филиалов — менее зависимым от ручного переноса данных.

Для университета — масштабируемым.

Именно поэтому RUC LMS важна не как ещё один образовательный сайт. Она показывает, что цифровизация начинается не с размещения уроков в интернете.

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

Настоящая цифровизация — это не когда бумажную форму перенесли на экран. Это когда лишнее ручное действие больше не требуется.

PANTELIDI

Финальная мысль

Можно было сделать отдельную страницу «Траектории», подключить оплату и закрыть материалы паролем.

Но через некоторое время появился бы второй курс. Потом третий. Понадобились бы новые сертификаты, новые преподаватели, новые отчёты и очередные ручные связки с внутренними системами.

Мы заложили это раньше.

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

Курс начинается с карточки в каталоге.

Но продукт начинается гораздо раньше — с правильно собранной системы.