Отчётность по обучению для учащихся, преподавателей и бизнеса

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

Кратко

Отчёт – это аналитика, подготовленная под решение конкретной аудитории. У продукта для обучения таких аудиторий три, и каждой нужен свой отчёт: учащемуся – прогресс и следующий шаг, преподавателю – кто застрял и на чём, бизнесу – доказательство, что обучение повлияло на результат. Самая частая ошибка – один дашборд на всех троих: на нём видно всё, но он ничего не подсказывает. Труднее всего с отчётом для бизнеса. Чтобы доказать ценность, нужно подняться по лестнице оценки от «прошли ли курс» через «изменилось ли поведение» к «какова отдача», а большинство программ застревает внизу: нужные данные лежат в HR-системе, CRM и журналах происшествий, а не в LMS. В российском продукте к трём читателям добавляются обязательные выгрузки: итоговые результаты – в ЭИОС вуза, сведения о документах ДПО – в ФИС ФРДО в течение 30 дней, итоги проверки знаний по охране труда – в реестр обученных лиц ЕИСОТ. Разберём, как спроектировать три отчёта, посчитать ROI и наладить обязательные выгрузки, а также какие нормы 152-ФЗ и Трудового кодекса определяют, кто что видит.

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

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

Отчёт – это аналитика под конкретное решение

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

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

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

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

Отчёт учащегося: прогресс и правильный следующий шаг

Учащийся открывает отчёт, чтобы понять две вещи: как у меня дела и что делать дальше? Хороший отчёт учащегося короткий, ободряющий и заканчивается действием. В нём виден прогресс по курсу (сколько модулей пройдено и сколько осталось), понятно, что уже освоено, а что стоит повторить, и есть один очевидный следующий шаг: «продолжить модуль 3 с 4:32» или «пересдать тест, где у вас 60%».

Данных для такого отчёта нужно немного, и они почти наверняка у вас уже есть. Стандарт передачи учебных событий Experience API (xAPI) записывает каждое событие короткой фразой из актора, глагола и объекта («Мария – завершила – модуль 3») и секции result, где могут храниться балл и признак завершения [1]. Отчёт учащегося по большей части – удобное представление этих результатов для одного актора. Если обучение построено на видео, xAPI Video Profile добавляет поле progress (доля просмотренного, от 0 до 1), и отчёт может показать точное «просмотрено 68%», а не оценку на глаз [3].

Отчёты учащихся чаще всего портят две ошибки. Первая – показывать учащемуся всё, что вы отслеживаете: сырые логи, каждое взаимодействие, внутренние баллы. Телеметрия ему не нужна, ему нужно понимать, где он находится и куда двигаться. Вторая – путать «просмотрено» и «изучено». Полоса прогресса на 100% означает, что видео доиграло до конца, но не означает, что человек чему-то научился. Показывайте просмотр и освоение отдельно и подписывайте их точно, иначе учащиеся начнут «докручивать» полоску вместо того, чтобы учиться. Эту ловушку мы подробно разбираем в статье Доля завершения: как определить, измерить и улучшить.

Отчёт преподавателя: кто застрял и где

Преподаватель, корпоративный тренер или куратор когорты открывает отчёт с другим вопросом: на кого и на что потратить ограниченное время? Его отчёт помогает расставить приоритеты. В нём есть кривая оттока когорты (момент в видео или модуле, где многие бросают), сложность заданий (вопросы теста, которые заваливают все, – обычно признак неудачного вопроса или непонятного урока, а не слабой группы) и список отстающих, которым стоит напомнить о себе.

Здесь одного признака завершения уже мало, и что вообще возможно, определяет стандарт, выбранный на этапе сбора данных. Поле played-segments из xAPI Video Profile – список фрагментов, которые каждый учащийся действительно посмотрел, – позволяет построить настоящую кривую оттока, а не догадку [3]. Родственный стандарт организации 1EdTech, Caliper Analytics, описывает те же видеовзаимодействия через MediaEvent [5]: если LMS заказчика работает с Caliper, слой отчётности может принимать и эти данные. Старый стандарт SCORM, напротив, записывает только фиксированный набор полей – завершение, балл, время – и видит курс как чёрный ящик. Поэтому курс только на SCORM скажет преподавателю, что учащийся закончил, но никогда не скажет, где группа потеряла интерес [7]. Если в вашей дорожной карте есть тепловая карта оттока для преподавателя, судьба этого обещания решилась ещё при выборе формата сбора данных; подробнее – в статье Трекинг видео через xAPI: Video Profile и что отслеживать.

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

Отчёт для бизнеса и лестница оценки

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

Классическая схема – модель Киркпатрика: четыре уровня оценки обучения, которыми пользуются с 1950-х годов [8]. Уровень 1, реакция: понравилось ли учащимся? (опрос после курса). Уровень 2, знания: выросли ли знания или навык? (балл теста). Уровень 3, поведение: стали ли люди иначе работать? (наблюдение на рабочем месте через несколько недель). Уровень 4, результат: сдвинулся ли показатель организации? (происшествия, продажи, обращения в поддержку, время выхода на полную продуктивность). Позже Джек Филлипс добавил пятую ступень – уровень 5, возврат на инвестиции (методология Phillips ROI): результат переводится в деньги, и денежная выгода программы сравнивается с её полной стоимостью [9].

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

Лестница показывает неприятную вещь. Большинство систем отлично отчитываются по двум нижним ступеням и почти ничего не говорят о трёх верхних: нижние плеер даёт сам (признак завершения, балл теста), а для верхних нужно связать данные обучения с бизнес-данными, которыми система обучения не владеет. Инструменты измерения тут ни при чём, это вопрос проектирования отчётности. Данные для верхних ступеней обычно есть, просто они лежат в HR-системе, CRM или журнале происшествий, а не в LMS. Поэтому отчёт о верхних ступенях начинается не с графика, а с договорённости с владельцами этих систем: какие поля, как часто и с какой степенью агрегации.

Пример расчёта ROI

Пятый уровень звучит солидно, но считается просто. Формула Phillips ROI даёт процент [9]:

«ROI (%) = (чистая выгода программы ÷ стоимость программы) × 100 где чистая выгода = (денежная ценность результата) − (стоимость программы)»

Возьмём конкретный и нарочно простой пример. Компания переводит теоретическую часть обучения по охране труда в видеокурс для 500 складских сотрудников. Полная стоимость – контент, доля затрат на платформу и рабочее время сотрудников на обучение – составляет 5,1 млн ₽. За следующий год число зарегистрированных происшествий снижается на 20, а финансовая служба уже оценивает среднее происшествие в 425 тыс. ₽: выплаты, простой, разбирательства.

«Денежная ценность результата = 20 происшествий × 425 тыс. ₽ = 8,5 млн ₽ Чистая выгода = 8,5 млн ₽ − 5,1 млн ₽ = 3,4 млн ₽ ROI = (3,4 млн ₽ ÷ 5,1 млн ₽) × 100 = 67%»

67% – цифра, которую можно защищать. Убедительной её делает то, что в отчёте нет заявлений вроде «обучение улучшило культуру безопасности». Он связывает измеренный бизнес-результат (на 20 происшествий меньше) с оценкой, которую финансовая служба уже приняла, и вычитает полную стоимость. Обоснованный отчёт от наивного отличает ещё одна оговорка: нужно показать, что число происшествий снизилось из-за обучения, а не просто после него (удачный год, новое оборудование, изменённый регламент). Это допущение стоит назвать открыто, а не прятать. Затратную часть уравнения помогает оценить статья Модель стоимости платформы обучения.

Отчёт ограничен тем, что вы собрали

Это сквозная тема всего раздела и мост к разработке: ни один отчёт не покажет того, чего не записал слой данных. Стандарт трекинга выбирают задолго до того, как кто-то попросит отчёт, и он задаёт потолок для всех будущих отчётов. Слой отчётности читает утверждения из хранилища учебных записей (LRS) через его API – по актору, активности или регистрации [4] – и может прочитать только то, что туда когда-то записали. В таблице – какие отчёты поддерживает каждый стандарт.

Если вы выбираете решение, определите самую высокую ступень, по которой когда-либо придётся отчитываться, и возьмите стандарт, который до неё дотягивается. Обещать бизнесу отчёт о результате 4-го уровня поверх курса только на SCORM – значит обещать то, чего данные не позволят. Стандарты мы сравниваем в статье SCORM, xAPI, cmi5 и LTI: какой стандарт и когда выбрать, а конвейер от сбора событий до хранилища, на котором держится бизнес-отчётность, строим в статье Создание конвейера аналитики обучения.

Обязательная отчётность: выгрузки со сроком

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

Вуз. Организация обязана создать электронную информационно-образовательную среду (ч. 3 ст. 16 273-ФЗ) [10], и итоговые результаты – оценки, зачёты, факт прохождения – логично вести там: чаще всего в Moodle или в собственной ЭИОС. Если видеоплатформа ведёт параллельный журнал, появляются два расходящихся журнала и ручная сверка в конце семестра. Рабочая схема: детальные события хранятся в собственном LRS, итог уходит в журнал ЭИОС через LTI или API; подробнее – в статье Интеграция с российскими LMS и ЭИОС вузов.

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

Охрана труда. Обучение требованиям охраны труда можно проводить с применением дистанционных технологий, кроме практических занятий по первой помощи, по применению средств индивидуальной защиты, на полигонах и тренажёрах (п. 66 ПП 2464) [13]. После проверки знаний работодатель, который сам обучает работников, или учебный центр передаёт сведения в реестр обученных лиц в ЕИСОТ Минтруда: ФИО, СНИЛС, профессию или должность, программу, результат («удовлетворительно» или «неудовлетворительно»), дату и номер протокола; учебный центр указывает ещё наименование и ИНН направившего работодателя. Сведения передаются импортом электронного документа по форме Минтруда (п. 118–119) [14]. По отраслевым разъяснениям, срок – 3 рабочих дня после проверки знаний, а за нарушения юрлицу грозит штраф по ст. 5.27.1 КоАП: 50–80 тыс. ₽, при повторном нарушении – 100–200 тыс. ₽ [15].

Во всех трёх случаях обязательная выгрузка – отдельный конвейер, а не ещё один дашборд. Ей нужны повторная отправка без дублей, журнал отправок, очередь ошибок с понятной причиной («нет СНИЛС», «не совпало ФИО») и ответственный, который заметит просрочку раньше проверяющего. Работает она по тому же правилу завершения, что и отчёт для бизнеса: если два отчёта считают «прошёл» по-разному, расхождение найдёт проверка.

Как сделать отчёт, которым пользуются

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

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

Сначала вывод, потом график. Первое, что видит читатель, – ответ словами: «Модуль 3 теряет 40% учащихся на 7-й минуте; рекомендуем перемонтировать этот фрагмент». График – доказательство под выводом, а не заголовок. Цифра без интерпретации перекладывает на читателя работу аналитика, а большинство делать её не станет.

У каждой цифры – сравнение. «320 завершений» ни о чём не говорит. «320 из 500 зачисленных (64%), в прошлом квартале было 78%» – уже повод действовать. Цифра без базы сравнения, цели или динамики – просто украшение.

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

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

Частая ошибка, которая обесценивает всю работу

Главный провал учебной отчётности – дашборд «всё сразу»: один экран со всеми метриками, которые умеет выдать система (среднее время просмотра, число входов, дюжина шкал), разосланный всем получателям одинаково. На демо он смотрится эффектно, а в работе бесполезен: не отвечает ни на чей конкретный вопрос, и каждому читателю приходится выискивать две важные для него цифры. Лечится это дисциплиной: начните с решения, покажите одну цифру со сравнением, которая к нему ведёт, напишите вывод простыми словами, остальное уберите. Качество отчёта определяется тем, что вы из него убрали.

Управление доступом: кто чьи данные видит

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

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

Этот принцип опирается на закон. 152-ФЗ требует, чтобы обработка персональных данных ограничивалась достижением конкретных, заранее определённых и законных целей, а содержание и объём данных соответствовали заявленным целям (ч. 2 и 5 ст. 5) [16]. Для сотрудников Трудовой кодекс говорит ещё конкретнее: доступ к персональным данным работников есть только у специально уполномоченных лиц, и они вправе получать лишь те данные, которые нужны для выполнения конкретных функций (ст. 88 ТК РФ) [17]. Наставник, который помогает своему учащемуся, выполняет понятную функцию; руководитель, который из любопытства листает баллы всех сотрудников, – нет.

Две особенности стоит заложить в проект с самого начала. Отметка об ОВЗ или инвалидности – это сведения о здоровье, то есть специальная категория персональных данных (ст. 10 152-ФЗ) [18]: она нужна, чтобы обеспечить учащемуся специальные условия, и не должна попадать в отчёты сверх необходимого. Хранилище отчётности, BI-инструмент и рассылка отчётов должны работать на серверах в России: операции с персональными данными граждан РФ с использованием баз данных за пределами РФ не допускаются (ч. 5 ст. 18 152-ФЗ) [19], так что зарубежный облачный BI для отчётов с именами не подходит. Если отчёты изначально разделены по аудиториям (индивидуальные данные для преподавателя, агрегат для бизнеса), эти требования выполняются самой архитектурой, а не доработками задним числом.

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

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

Сам отчёт тоже должен быть доступным

О последнем требовании в продуктах для обучения часто забывают: отчёт – это тоже контент, и среди его читателей есть учащиеся и сотрудники с нарушениями зрения. Технический ориентир – Web Content Accessibility Guidelines, WCAG 2.1 уровня AA [6]; в России на нём основан национальный ГОСТ Р 52872-2019 [20]. Стандарт добровольный, пока на него не сошлются договор или техническое задание, но проверять интерфейсы разумно именно по нему. Для дашбордов важнее всего критерий успеха 1.4.1 «Использование цвета» (уровень A): цвет не должен быть единственным визуальным способом передать информацию [21]. График оттока, где когорты различаются только цветом, не прочитает примерно каждый двенадцатый мужчина – у стольких есть нарушение цветовосприятия. Решение – двойное кодирование: дополните цвет подписью, формой или штриховкой, чтобы смысл сохранялся и в оттенках серого. В пояснениях к WCAG отмечено, что разница в светлоте считается дополнительным признаком, только если контраст двух тонов не ниже 3:1 [21]. Полный разбор стандарта – в статье WCAG 2.1 AA и ГОСТ Р 52872-2019 для учебного видео.

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

Фора Софт с 2005 года разрабатывает ПО для видеостриминга, видеосвязи на WebRTC и интерактивных плееров. В продуктах для обучения хорошая инженерная работа чаще всего пропадает зря именно на уровне отчётности: команды собирают богатые данные, а потом выпускают один общий дашборд, на который никто не реагирует. Граница между «купить» и «разработать» здесь понятна. Готовая система даёт отчёты о завершении из коробки, и этого достаточно, если «кто прошёл» – единственный вопрос, который вам зададут. Собственная отчётность нужна, когда бизнес требует доказать результат и ROI, когда трём аудиториям нужны действительно разные представления, когда данные обучения надо связать с HR-системой или CRM или когда результаты нужно надёжно выгружать в ЭИОС, ФИС ФРДО или реестр ЕИСОТ. Мы помогаем командам решить, какие отчёты стоят разработки, а затем настраиваем сбор данных, ролевой доступ и представления для каждой аудитории на серверах в России, чтобы каждый отчёт вёл к решению, ради которого он создан. Тот же подход «от данных к решению» мы применяем в видеосвязи, телемедицине, OTT и видеонаблюдении.

Главное

• Отчёт – это аналитика под решение одной аудитории; если решение назвать нельзя, перед вами дашборд.
• Три аудитории – три отчёта: учащийся (следующий шаг), преподаватель (кто застрял), бизнес (результат и ROI).
• Поднимайтесь по лестнице оценки: четыре уровня Киркпатрика плюс Phillips ROI; большинство отчётов не идёт дальше двух нижних.
• Отчёт не покажет то, что не собрано; выбирайте стандарт под самую высокую ступень, которая понадобится.
• Обязательные выгрузки – ЭИОС, ФИС ФРДО (30 дней), реестр обученных по охране труда в ЕИСОТ – это отдельный конвейер с журналом и очередью ошибок.
• Начинайте с вывода, снабжайте каждую цифру сравнением и подбирайте периодичность под решение.
• Разграничивайте доступ по аудиториям: учащийся видит себя, преподаватель – своих, бизнес – агрегат (ст. 5 152-ФЗ, ст. 88 ТК РФ); данные хранятся в РФ.

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

• Аналитика обучения: какие метрики важны, а какие вводят в заблуждение
• Создание конвейера аналитики обучения
• Доля завершения: как определить, измерить и улучшить
• Интеграция с корпоративными LMS и HR-системами