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

Для IT-команд это знакомая картина. Внутренние знания расползаются по Confluence, GoogleDocs, тикетам, чатам и личным заметкам экспертов. Часто самые важные детали существуют только в голове у нескольких сотрудников, которые и без того заняты релизами, инцидентами и созвонами. Новичок вынужден собирать рабочий контекст по кусочкам, а наставник превращается в «живой яндекс» по корпоративной памяти.

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

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

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

Почему процента прохождения курсов недостаточно

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

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

В этой ситуации процент прохождения курса ничего не объясняет. Он не показывает:

• начал ли сотрудник выполнять рабочие задачи без постоянной помощи;

• снизилось ли число ошибок и возвратов на доработку;

• сократилось ли время до достижения плановых KPI;

• окупились ли часы экспертов, HR-команды и самого новичка.

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

1. Время до самостоятельной работы или Time to Productivity

Это период от первого рабочего дня или завершения обучения до момента, когда сотрудник достигает согласованного уровня продуктивности.

Ключевое слово здесь — «согласованного». Нельзя измерять время выхода на продуктивность без определения, где этот момент для конкретной роли. Для разработчика это может быть выполнение задач определённой сложности без регулярных доработок. Для специалиста поддержки — соблюдение SLA и допустимый процент эскалаций. Для менеджера по продажам — выполнение минимального плана или стабильная конверсия.

Формула простая:

Например, новый DevOps-инженер начал работать 1 марта. Команда заранее определила критерий: сотрудник самостоятельно закрывает типовые инциденты, соблюдает SLA и не нуждается в ежедневной проверке наставника. Этот уровень достигнут 15 апреля. Значит, Time to Productivity составило 45 дней.

Само по себе число мало о чём говорит. Его ценность появляется в динамике. Если до пересборки онбординга медианное время составляло 60 дней, а после — 45, то команда получила заметный операционный эффект. Новички раньше берут задачи в работу, наставники меньше отвлекаются, а руководитель точнее планирует загрузку.

Чтобы метрика не превратилась в ручной квест, стоит заранее определить источники данных:

• дату выхода сотрудника — из кадровой системы;

• дату завершения обязательных модулей — из платформы обучения;

• данные о задачах, SLA, ошибках или продажах — из рабочих систем;

• оценку самостоятельности — из чек-листа руководителя или наставника.

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

2. Удержание новичков — Retention

Вторая метрика — доля сотрудников, которые остаются в компании после определённого периода. Чаще всего считают удержание на 90-й день и через 12 месяцев после трудоустройства.

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

Формула удержания на 90-й день:

Допустим, в январе команда наняла 40 специалистов поддержки. К концу 90-дневного периода в компании остались 34 человека. Retention 90 составит 85%.

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

Например, можно сравнить две группы новичков:

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

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

3. Окупаются ли вложения — ROI обучения

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

Классическая формула выглядит так:

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

• сокращение времени до выхода на продуктивность;

• снижение количества ошибок;

• уменьшение повторных обращений в поддержку;

• сокращение задействования наставников;

• снижение затрат на повторный подбор из-за раннего ухода.

Например, команда из 20 новичков после обновления онбординга выходит на целевой уровень на 10 рабочих дней раньше. Если средняя стоимость одного рабочего дня сотрудника для бизнеса составляет 5 000 рублей, потенциальный эффект можно оценить так:

20 х 10 х 5 000 = 1 000 000

Пусть на разработку программы, настройку платформы и участие экспертов потратили 400 000 рублей. Тогда:

ROI=1 000 000 - 400 000 / 400 000 х 100%= 150%

Это упрощённый пример. В реальном расчёте важно явно зафиксировать допущения и не подменять экономический эффект красивыми цифрами. Но даже консервативная модель лучше, чем отчёт вида «проведено 18 вебинаров».

Как собрать метрики в один отчёт

Эти показатели работают лучше вместе, а не по отдельности.

Логика отчёта может быть такой: после обновления базы знаний и программы адаптации сократилось время выхода на KPI; одновременно выросло удержание новичков; финансовый эффект от более быстрой самостоятельной работы превысил затраты на создание и поддержку обучения.

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

Не ждите идеальных данных

В ИТ легко отложить такую работу до «лучшего момента»: когда переедем на новую кадровую систему, закончим внедрение бизнес-аналитики (BI), наведём порядок в базе знаний или появится свободная команда. Но обычно этот момент не наступает. Зато продолжают расти количество каналов, документов и внутренних сервисов; опытные сотрудники тратят часы на повторяющиеся объяснения; новички месяцами добирают рабочий контекст.

Не нужно начинать с глобального проекта по цифровой трансформации обучения. Выберите одну команду или массовую роль, где цена медленной адаптации особенно заметна. Например, поддержку, разработку, DevOps, внедрение или Customer Success. Зафиксируйте текущую скорость онбординга (Time to Productivity), посмотрите удержание на 90-й день и оцените стоимость одного дня, когда сотрудник ещё не работает самостоятельно.

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

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

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

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