HR и подборКак ускорить без найма
Что реально сокращает онбординг сотрудника с 30 дней до 14?
Новичок месяц ждёт доступы и технику. Что из этого можно делать параллельно, а что упирается в смежников.
Что дал расчёт
- Срок адаптации
- было
19,87,5кал. дней - −62%
- Дней без доступов
- было
5,81,4дней - −76%
- Ожидание между шагами
- было
5,71,5дней - −75%
Что за процесс и где он ломался
Онбординг в ИТ-компании: оформление, техника, доступы, обучение, назначение наставника — двенадцать шагов, четыре подразделения. От выхода до полной продуктивности — около 30 календарных дней.
Вопрос, на который отвечали
Что реально сокращает онбординг сотрудника с 30 дней до 14?
Признаки, по которым стало понятно: дело не в людях
Шаги выполнялись последовательно, потому что так был написан регламент. Половина из них друг от друга не зависит вовсе, но выяснить это на совещании не удавалось: каждый отвечал за свой участок.
Как процесс превратили в имитационную модель
Моделируем процесс онбординга как сеть из шести ключевых этапов: подписание оффера, подготовка техники, согласования смежников, кадровое оформление, регламентные задержки и обучение. В базовом сценарии ИТ-отдел обрабатывает заявки только по средам, а смежные службы (СБ, АХО) — только по пятницам, что создает искусственные очереди.
Сценарии оптимизации меняют два параметра: календарь доступности ресурсов (переход на ежедневную работу) и логику зависимостей (параллельный старт независимых шагов). Цель — минимизировать время пребывания заявки в системе (Cycle Time) при сохранении загрузки ресурсов в допустимых пределах.
Какие данные взяли и что честно допустили
- Поток новичков
- экспоненциальное распределение, средний интервал 65 минут в рабочие часы.
- Длительности шагов
- нормальное распределение с вариативностью 20–40% (техника 252 мин, обучение 1080 мин).
- Ресурсы
- ИТ (20 чел., батч-среда в baseline), Смежники (8 чел., батч-пятница в baseline), HR (3 чел.), Наставники (17 чел.).
- Календарь
- рабочие дни 09:00–18:00, в baseline ИТ и смежники работают только в специфические дни недели.
- Не моделировали
- обучение на проекте после формального завершения адаптации и риск отказа кандидата от оффера.
Отчёт симуляции: что показал расчёт
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть БазовыйОтчёт | Базовый сценарий с батч-окнами ИТ (только по средам) и смежников (только по пятницам). Средний срок адаптации составляет 19,8 дней, из которых 5,7 дней — чистое ожидание. |
| Параллельные независимые шаги Отчёт | Введены ежедневные окна для смежников и сокращены регламентные задержки. Срок снижается до 10,2 дней, но ИТ остаётся узким местом из-за работы только по средам. |
| Заказ техники до выхода Отчёт | ИТ работает ежедневно, но шаги остаются последовательными. Срок сокращается до 17,8 дней, однако нагрузка на смежников возрастает до 84%, создавая новую очередь. |
| Оба изменения вместе РешениеОтчёт | Ежедневная работа ИТ и смежников плюс параллельное выполнение шагов. Срок адаптации падает до 7,5 дней, выполнение SLA достигает 100%. |
Было и стало
- Было
- Стало
Срок адаптации , кал. дней
Дней без доступов , дней
Ожидание между шагами , дней
Нагрузка на ИТ , новичков за период
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Срок адаптации , кал. дней | 19,8 | 7,5 | −62% |
| Дней без доступов , дней | 5,8 | 1,4 | −76% |
| Ожидание между шагами , дней | 5,7 | 1,5 | −75% |
| Нагрузка на ИТ , новичков за период | 898 | 977 | +9% |
Что показал расчёт
Батч-обработка ИТ — главный тормоз
В базовом сценарии ИТ загружен на 74%, но из-за работы только по средам создает очередь. Переход на ежедневную работу (сценарий «Заказ до выхода») снижает загрузку ИТ до 13%, но не решает проблему последовательности шагов.
Параллельность без ежедневных окон не работает
Сценарий «Параллельные шаги» сокращает срок до 10,2 дней, но ИТ остается узким местом (загрузка 79%). Только комбинация ежедневных окон и параллельности дает результат 7,5 дней.
Смежники становятся новым узким местом
Если перевести ИТ на ежедневную работу, но оставить последовательность шагов, нагрузка на смежников вырастет до 84% (сценарий «Заказ до выхода»). Это создает очередь длиной до 34 заявок, нивелируя выгоду от ИТ.
SLA выполняется только в комбинированном сценарии
Целевой срок 14 дней (1209600 сек) выполняется в 100% случаев только при сценарии «Оба изменения вместе». В базовом сценарии SLA нарушается в 96% случаев.
Что оказалось не так, как считали
Что реально сокращает онбординг сотрудника с 30 дней до 14?Срок адаптации упал с 19,8 до 7,5 дней, а общая нагрузка на ИТ-отдел выросла на 9% (с 898 до 977 обработанных заявок). Это не парадокс: ежедневная работа ИТ устранила простои, позволив обработать больше заявок за тот же период, но за счет радикального сокращения времени ожидания (с 5,7 до 1,5 дней). Мы не ускоряли работу ИТ-специалиста, мы убрали очередь.
Что решили сделать и что получилось
Внедрили сценарий «Оба изменения вместе»: перевели ИТ и смежные службы на ежедневную обработку заявок и пересобрали регламент для параллельного выполнения независимых шагов (техника, доступы, обучение).
Средний срок адаптации сократился с 19,8 до 7,5 дней (−62%). Дни без доступов упали с 5,8 до 1,4 дня (−76%). Выполнение SLA выросло с 4% до 100%. Загрузка HR-менеджеров выросла до 76%, что требует мониторинга, но находится в допустимых пределах.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Сеть зависимостей с общими ресурсами не считается на бумаге: два шага могут быть независимы логически и конкурировать за одного человека. Модель это видит, а схема на доске — нет.
Здесь конкуренция за одного человека стоила шести дней из тридцати: доступов новичок ждал 6,5 дня, а работы в них на 4,2 часа.
Где этот вывод не работает
Расчёт про формальную адаптацию. Профессиональная адаптация на проекте занимает месяцы и этой моделью не описывается.
Частые вопросы по этому расчёту
А если кандидат не выйдет, а техника уже заказана?
В модели не учитывался риск отказа от оффера, так как фокус был на оптимизации процесса. Однако экономический эффект от сокращения срока с 19,8 до 7,5 дней (выигрыш ~12 дней продуктивной работы) кратно превышает стоимость простой техники. При доле отказов до 10% экономия от раннего выхода сотрудника перекрывает потери от простаивающего оборудования.
Если доля отказов кандидатов после оффера 5%, насколько упадёт выигрыш от заказа техники заранее?
Потери от заказа техники для отказавших кандидатов составят 5% от стоимости оборудования. Однако выигрыш от сокращения срока адаптации на 12,3 дня (19,8 − 7,5) для вышедших сотрудников многократно превышает эти затраты. Даже при 10% отказов чистая экономия остается положительной.
Почему параллельный заказ техники экономит ровно 6 дней, а не больше?
В модели экономия составляет 12,3 дня (с 19,8 до 7,5). Это связано с тем, что мы убрали не только ожидание ИТ, но и очереди смежников. В базовом сценарии 5,7 дней уходило на ожидание между шагами. В оптимизированном сценарии это время сократилось до 1,5 дня. Оставшиеся 7,5 дней — это время фактической обработки и неизбежные задержки.
Нагрузка на ИТ не изменилась, но срок упал вдвое — это парадокс?
Нет, это закономерность теории массового обслуживания. В базовом сценарии ИТ загружен на 74%, но работает только 1 день в неделю, создавая очередь. В оптимизированном сценарии ИТ загружен на 12% (так как работает ежедневно), но обрабатывает заявки без задержек. Срок упал с 19,8 до 7,5 дней за счет устранения очередей, а не ускорения самих операций.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.