Один сорванный первый рабочий день обычно собирает классический набор: нет ноутбука, не заведена учётка, пропуск где-то между безопасностью и офисом, а в Excel уже давно лежит чеклист на два десятка пунктов. В материале SimpleOne, о котором сообщает Habr / Карьера, предлагают лечить онбординг сотрудников не новыми напоминаниями в чатах, а старыми ИТ-приёмами: каталогом услуг, SLA, RACI и заявками с понятным владельцем процесса. Для русскоязычного IT-рынка это сигнал простой: онбординг сотрудников всё чаще рассматривают не как «зону HR», а как сквозной сервис, где провал на любом стыке бьёт по бизнесу, репутации команды и скорости выхода человека в работу.
Исходный тезис у авторов довольно приземлённый, поэтому и цепляет. На бумаге всё выглядит прилично: HR отправляет оффер, ИТ готовит доступы и технику, АХО организует рабочее место, служба безопасности оформляет пропуск, бухгалтерия заводит сотрудника в расчётную систему. На практике это часто набор разрозненных действий, которые живут в письмах, таблицах и устных договорённостях. Каждый видит только свой кусок и свои сроки, а общего тайминга нет. В итоге формально человек трудоустроен, фактически работать ему нечем. И, как это обычно бывает в корпоративной экосистеме, крайним назначают того, кто общался с кандидатом последним и обещал, что всё будет готово, то есть HR.
Авторы статьи предлагают посмотреть на ситуацию глазами ИТ-поддержки, которая, по их формулировке, училась структурировать такой хаос примерно три десятилетия. Там давно отказались от логики «ну вы мне ещё раз напомните» в пользу сервисной модели: любая просьба превращается в заявку, у неё есть описание, срок, исполнитель и статус. Для HR это означает довольно неприятную, но полезную мысль: пока онбординг сотрудников держится на героизме рекрутера или HRBP, который вручную пингует ИТ, безопасность и офис, процесс в любой момент развалится. Не потому, что кто-то ленив, а потому что ручная координация плохо масштабируется и почти не переживает отпуск, аврал или резкий рост найма.
Главный инструмент, который предлагают перенести из Service Desk в кадровые процессы, это каталог услуг. В ИТ никто не работает с абстрактным «помогите»: есть понятные сервисы вроде создания учётной записи, выдачи ноутбука или открытия доступа к конкретной системе. По той же логике HR можно разложить на набор стандартных услуг: онбординг, оформление оффера, перевод между командами, отпуск, обучение, командировки, exit-процессы. Для бизнеса это не косметика и не новое название старого бардака, а способ зафиксировать входы и выходы процесса. Сотрудник и менеджер понимают, что именно можно запросить и в каком формате, а HR-команда перестаёт делать вид, что каждый кейс уникален как снежинка. Чем типичнее сценарий описан, тем проще его автоматизировать и тем меньше шансов, что критичная задача зависнет в переписке без хозяина.
Второй слой, без которого эта схема быстро превращается в красивую диаграмму на презентации, это SLA и роли. В статье подчёркивается, что для «здорового» онбординга мало договориться только с HR о сроках оффера или ответа кандидату. Нужны сквозные обязательства: за сколько дней до выхода фиксируются все данные, когда ИТ обязано подготовить учётки и оборудование, в какие сроки АХО и безопасность закрывают рабочее место и пропуск, когда финансы заводят сотрудника в систему. Отсюда логично вырастает и RACI-матрица. Кто делает шаг, кто отвечает за результат, кого нужно консультировать, кого держать в курсе. На практике это убирает самую токсичную часть процесса: зависшие handoff'ы между подразделениями, когда HR уверен, что передал задачу дальше, ИТ считает её несрочной, безопасность ждёт подтверждения, а бухгалтерия узнаёт о новичке в последний момент. После разметки ролей вопрос «почему не готово» адресуется не в пустоту и не в общий чат, а конкретному владельцу шага.
Отдельно важен тезис про метрики, потому что именно здесь у кадровых функций обычно заканчивается романтика и начинается управленческая польза. ИТ-подразделения давно меряют время исполнения заявок, соблюдение SLA и точки, где процесс ломается чаще всего. В HR авторы предлагают считать не только количество нанятых людей, но и среднее время от принятого оффера до полноценного выхода в работу, долю случаев с полностью или частично сорванным первым днём, а также подразделения и этапы, на которых заявки буксуют чаще всего. У такого подхода есть неприятный побочный эффект: он быстро снимает удобные иллюзии. Может оказаться, что HR свою часть делает без сбоев, а основное узкое место сидит в ИТ или АХО. Может выясниться и обратное. Но для бизнеса это как раз плюс: вместо ритуального поиска виноватого появляется карта задержек, на которую можно повесить ответственность, автоматизацию и бюджет.
Практический сценарий в статье описан без особой магии. Всё стартует с одной осмысленной заявки на приём сотрудника, где фиксируются ФИО, позиция, команда, дата выхода, формат работы, список доступов и нужное оборудование. Дальше система, если она есть, раскидывает этот запрос на набор задач для разных служб: HR оформляет документы и приветственное письмо, ИТ заводит учётки и готовит ноутбук, АХО и офис-менеджер обеспечивают рабочее место и пропуск, безопасность закрывает свои проверки, бухгалтерия и финансы настраивают зарплатную часть. Ценность тут не в самой автоматизации, а в прозрачности. Если всё готово вовремя, никто ничего не замечает, новичок просто начинает работать. Если нет, проблема видна сразу: застряла конкретная задача, у неё есть конкретный статус и конкретный исполнитель. Для компаний, которые продолжают масштабировать найм даже в осторожном режиме, это уже не удобство, а способ не тратить первые дни сотрудника на экскурсию по корпоративным бутылочным горлышкам.
В сухом остатке идея статьи выглядит сильнее, чем типичный HR-совет из серии «лучше коммуницируйте». Авторы фактически говорят, что онбординг сотрудников пора перестать считать цепочкой одолжений между отделами и начать собирать как сервис с измеримым результатом. Если этот подход приживётся шире, HR в ИТ-компаниях станет меньше похож на диспетчера аварийной смены и больше на владельца процесса с нормальными инструментами управления. И тогда вопрос у рынка будет уже не в том, нужен ли сервисный подход в кадрах, а в том, почему его не внедрили раньше, пока ноутбук новичка ещё можно было искать по чатам без ущерба для бизнеса.