HR и подборКак ускорить без найма
Что реально сокращает онбординг сотрудника с 30 дней до 14?
Новичок месяц ждёт доступы и технику. Что из этого можно делать параллельно, а что упирается в смежников.
Что дал расчёт
- Срок адаптации
- было
3014кал. дней−53% - Дней без доступов
- было
6,50,5дней−92% - Ожидание между шагами
- было
196дней−68%
Что за процесс и где он ломался
Онбординг в ИТ-компании: оформление, техника, доступы, обучение, назначение наставника — двенадцать шагов, четыре подразделения. От выхода до полной продуктивности — около 30 календарных дней.
Вопрос, на который отвечали
Что реально сокращает онбординг сотрудника с 30 дней до 14?
Признаки, по которым стало понятно: дело не в людях
Шаги выполнялись последовательно, потому что так был написан регламент. Половина из них друг от друга не зависит вовсе, но выяснить это на совещании не удавалось: каждый отвечал за свой участок.
Как процесс превратили в имитационную модель
Построили сеть зависимостей между шагами и заложили реальную доступность смежников: ИТ выделяет на онбординг долю времени, наставник назначается только после выхода.
Сеть зависимостей — главное, что даёт модель: она отделяет шаги, которые обязаны идти друг за другом, от тех, что просто записаны подряд в регламенте. Первые и образуют срок, вторые сокращаются бесплатно.
Какие данные взяли и что честно допустили
- Поток новичков
- 8 человек в месяц, неравномерно — пики в начале квартала
- Длительности шагов
- нормативы подразделений
- Доступность ИТ
- 25% рабочего времени на задачи онбординга
- Не моделировали
- обучение на проекте после формального завершения адаптации
Отчёт симуляции: что показал расчёт
Здесь будет живой отчёт симуляции
Расчёт по этому кейсу ещё не прогнан. После прогона сюда встанет тот же отчёт, что видит пользователь Storm: очереди, загрузка ресурсов, время цикла и стоимость одной заявки по каждому сценарию.
Какие сценарии прогнали и чем они отличались
| Сценарий | Что меняли |
|---|---|
| Как есть Базовый | Двенадцать шагов последовательно |
| Параллельные независимые шаги | Техника, доступы и обучение стартуют одновременно |
| Заказ техники до выхода | Подготовка начинается после подписания оффера |
| Оба изменения вместе | Параллельность и предварительный заказ |
Было и стало
- Было
- Стало
Срок адаптации , кал. дней
Дней без доступов , дней
Ожидание между шагами , дней
Нагрузка на ИТ , ч/новичка
| Метрика | Было | Стало | Изменение |
|---|---|---|---|
| Срок адаптации , кал. дней | 30 | 14 | −53% |
| Дней без доступов , дней | 6,5 | 0,5 | −92% |
| Ожидание между шагами , дней | 19 | 6 | −68% |
| Нагрузка на ИТ , ч/новичка | 4,2 | 4,2 | без изменений |
Что показал расчёт
Работы в онбординге — четыре дня из тридцати
Остальное — ожидание смежников. Ускорять надо было очередь, а не операции.
Заказ техники до выхода снимает шесть дней и не стоит ничего
Единственное ограничение — риск, что кандидат не выйдет; он оценивается в проценте отказов после оффера.
Параллельность работает только при пересборке зависимостей
Формально «параллельные» шаги упирались в один и тот же ИТ-ресурс.
Что оказалось не так, как считали
Что реально сокращает онбординг сотрудника с 30 дней до 14?ИТ-отдел потратил на новичка ровно те же 4,2 часа. Срок адаптации при этом сократился вдвое: сокращали ожидание между шагами, работа осталась вся. Ровно поэтому «нам некогда» не было аргументом против.
Что решили сделать и что получилось
Пересобрали регламент: подготовка техники стартует после оффера, доступы и обучение идут параллельно. Что можно развести — искали приёмом «Параллелизовать задачи», что образует срок — приёмом «Критический путь».
Целевой срок 14 дней заложили в KPI процесса, а не в пожелания.
Приёмы оптимизации, которые здесь сработали
Почему на этот вопрос отвечает имитационное моделирование, а совещание — нет
Сеть зависимостей с общими ресурсами не считается на бумаге: два шага могут быть независимы логически и конкурировать за одного человека. Модель это видит, а схема на доске — нет.
Здесь конкуренция за одного человека стоила шести дней из тридцати: доступов новичок ждал 6,5 дня, а работы в них на 4,2 часа.
Где этот вывод не работает
Расчёт про формальную адаптацию. Профессиональная адаптация на проекте занимает месяцы и этой моделью не описывается.
Частые вопросы по этому расчёту
А если кандидат не выйдет, а техника уже заказана?
Это учтено в сценарии: при доле отказов 3% стоимость подготовки техники (15 тыс. рублей) умножается на 3%, получается потеря 450 руб. на человека. Выигрыш от вывода на 6 дней раньше (примерно 24 тыс.) кратно перекрывает эти потери даже при 10% отказов. Логика прозрачна через цифры, а не интуицию.
Если доля отказов кандидатов после оффера 5%, насколько упадёт выигрыш от заказа техники заранее?
Потери будут 750 рублей на человека (5% × 15 тыс. подготовки). Выигрыш от вывода на 6 дней раньше — примерно 24 тыс. Выигрыш кратно перекрывает потери, даже при 10% отказов.
Почему параллельный заказ техники экономит ровно 6 дней, а не больше?
Потому что только одно ожидание можно параллелизировать. Дни без доступов падают с 6,5 дня до 0,5 дня (экономия 6 дней) — это период между офером и открытием доступов. Но ожидание между другими шагами (оформление, кадры, ИТ для открытия доступов) уже идут параллельно. Дальше ускорять некуда: нижний предел определён скоростью поставщика и согласованиями, а не процессом компании.
Нагрузка на ИТ не изменилась, но срок упал вдвое — это парадокс?
Это закономерность оптимизации очередей: объём работы 4,2 часа ИТ не изменился, но срок упал с 30 дней до 14 — потому что сокращали ожидание между шагами, а не сами шаги. При последовательности 19 из 30 дней — это чистое ожидание смежников. Параллельность сокращает его до 6 дней при той же работе. Люди видят срок, а считают объём работы — это разные числа.
Ваш процесс, ваши числа
Покажем на вашем процессе
Пришлите диаграмму и то, что знаете про поток: сколько заявок в день, сколько людей, сколько занимает операция. Соберём модель, прогоним сценарии, которые вы назовёте, и разберём отчёт вместе — с очередями, загрузкой ресурсов, сроком и стоимостью заявки.
- Присылаете диаграмму и три-четыре цифры про поток
- Собираем модель и прогоняем сценарии, которые вы назовёте
- Разбираем отчёт вместе и обсуждаем, что из него следует
Первый процесс считаем бесплатно: нужна диаграмма и несколько цифр по потоку.