Первый день новичка сорван: нет учётки, ноутбука и пропуска, хотя HR всё согласовал. В почте — бесконечная переписка с ИТ, безопасностью и АХО, в Excel — чеклист из двадцати пунктов, в мессенджерах ещё пара чатов. 

Но в глазах сотрудника виноват один человек — HR, потому что именно он обещал, что всё будет готово. 

В ИТ такой цирк научились хотя бы структурировать лет тридцать назад: завели каталог услуг, договорились о SLA, перестали забывать задачи и начали мерить, где именно всё ломается. В этой статье посмотрим, как эту же сервисную логику перенести в HR, чтобы навести порядок на стыках и отвечать за результат, а не за бесконечные напоминания.

Как обычно, дисклеймер: да, мы разрабатываем ESM-платформу. Но продавать её в этой статье не будем — сервисная логика работает и без нас.

Онбординг без скелета

На бумаге онбординг в порядке: HR отправляет оффер, ИТ готовит доступы, АХО организует рабочее место, безопасность оформляет пропуск, бухгалтерия заводит в зарплатную систему. Но часто это набор разрозненных кусочков, которые живут в разных мирах: что‑то в письмах, что‑то в таблице, где-то просто договорились на словах.

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

Хендоффы теряются именно на стыках: HR считает, что передал дальше и задача двигается, ИТ считает, что сделает, когда руки дойдут, АХО не видит срочности, безопасность ждёт подтверждения, бухгалтерия узнаёт о новом человеке в последний момент. Задачи фактически висят в воздухе — у них нет прозрачного статуса и понятного ответственного, только переписка и устные договорённости.

И в этой конструкции HR неизбежно становится узким местом и одновременно главным виноватым. Человек, который изначально должен заниматься людьми, вынужден превращаться в живой Service Desk: вручную трекать все обещания, пинговать коллег, вспоминать, кто кому что обещал две недели назад. При этом операционная ответственность за многие шаги онбординга лежит на других командах — но негатив от сорванного первого дня аккуратно приземляется именно на HR.

Всё это потому что процесс построен на ручной координации, а не на сервисной модели. Пока онбординг — это набор писем и Excel‑таблиц, порядка не будет, независимо от того, насколько вы сильны как HR‑команда.

Что HR может взять из практик ИТ-поддержки

ИТ‑поддержка давно живёт в мире, где ничего не должно теряться: любая просьба превращается в заявку с понятным описанием, сроком и ответственным. Проблема «забыли выдать ноут» там решена не мотивационными постерами, а структурой процесса. Для HR это готовый набор паттернов, который можно почти напрямую перенести в кадры, без необходимости становиться админом или ITIL‑гуру.

Каталог услуг: разобрать HR на «сервисы»

В Service Desk нет абстрактного «помогите», есть конкретные услуги: «создать учётную запись», «выдать ноут», «открыть доступ к системе».

Это может быть неочевидно, но HR в какой-то степени можно организовать так же: онбординг, оффер, перевод между командами, отпуск, обучение, командировки, exit‑процессы — всё это отдельные услуги с чётким описанием, входами и выходами.

С помощью каталога сотрудник и бизнес понимают, о чём вообще можно попросить HR и в каком формате. Внутри HR команда перестаёт жить в режиме «каждый кейс уникален» — есть типовые сценарии, постоянно изобретать велосипед не нужно. И всё это вдобавок легче автоматизировать: каждый сервис превращается в форму/заявку, которую можно запустить и дальше уже трекать по шагам.

SLA, соглашение об уровне обслуживания

В ITIL понятие Service Level Agreement — это по сути договор «как быстро мы делаем типовые вещи». В HR‑контексте SLA обычно понимают как «за сколько дней HR должен прислать оффер или ответить кандидату». Но если говорить про сквозные услуги, такие как онбординг, SLA нужны не только HR.

Минимальный набор для «здорового» онбординга:

• HR: за сколько дней до выхода сотрудника фиксируются все данные и согласования.

• ИТ: за сколько времени готовятся учётки, ноут, доступы.

• АХО: за сколько времени готовится рабочее место и пропуск.

• Бухгалтерия/финансы: за сколько времени сотрудник заводится в систему расчёта.

Так появляется общий SLA на онбординг: не каждый делает что‑то когда сможет, а через N дней после старта процесса у человека есть всё, чтобы работать.

Матрица RACI

Ещё одна вещь, которую ИТ принесло в управляемые процессы — матрица RACI: Responsible, Accountable, Consulted, Informed. В нормальной системе это часть настройки процесса: роли и уведомления завязаны на R и A, C и I получают свои точки входа в онбординг.

Если разложить онбординг в RACI, становится понятнее:

После этого исчезают висящие задачи без хозяина. У каждого шага есть понятный R и A, а значит, есть к кому прийти с вопросом почему не сделано и кому давать инструменты для улучшения.

Метрики для решений

ИТ‑команды давно измеряют свою работу: время исполнения заявки, количество инцидентов, SLA‑выполнение, точки, где чаще всего происходят сбои.

В HR‑онбординге можно считать не только сколько наняли, но и:

• Среднее время онбординга от принятого оффера до полноценной работы сотрудника.

• Долю случаев, когда первый день сорван или частично сорван (нет доступа, нет ноутбука, нет пропуска).

• В каких подразделениях заявки чаще всего застревают и на каких шагах.

Эти цифры быстро снимают иллюзии. Иногда оказывается, что HR делает свою часть идеально, а 80% срывов приходятся на ИТ или АХО. Иногда наоборот — внутри HR есть бутылочное горлышко. В любом случае появляется точка опоры и конкретные места, где сервисный подход даёт максимальный эффект.

Онбординг как сервисный процесс: сценарий «принять сотрудника»

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

HR заполняет заявку «принять сотрудника», где фиксирует данные — ФИО, позицию, команду, дату выхода, формат работы, нужные доступы и оборудование. Дальше ESM-система, если она есть, может сама раскидать эту заявку в комплект задач для разных команд:

• HR — оформить договор, завести в HR‑систему, подготовить приветственное письмо.

• ИТ — завести учётку, выдать ноутбук, настроить доступы к нужным системам.

• АХО/офис‑менеджер — подготовить рабочее место, заказ пропуска, базовая инфраструктура.

• Безопасность — проверки, доступы к помещениям, регламенты.

• Бухгалтерия/финансы — завести карточку сотрудника, настроить начисление зарплаты и бенефитов.

У каждой задачи свой исполнитель, сроки и статус. Когда всё готово вовремя, этого никто не замечает — новичок просто садится в первый день и работает. А вот когда что-то не готово, сразу видно, что именно застряло и на ком: не «где-то потерялось письмо», а конкретная задача с конкретным ответственным.

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

HR становится владельцем онбординга как процесса.

• У него есть единая точка правды по каждому новичку: одна заявка и связанный набор задач.

• Он управляет SLA: видит, какие шаги укладываются в сроки, а какие системно проваливаются.

• Он может показать бизнесу, где проблема — в ИТ, в АХО, в безопасности или внутри самого HR.

Списывайте, но не прям точь-в-точь

Важно честно признать, что ITIL и сервисный подход — это не универсальный шаблон, который можно просто приложить к HR и всё станет идеально. У HR есть своя специфика, и если её игнорировать, получится не управляемый сервис, а бюрократический монстр, который всех раздражает и мало кому помогает.

• Во‑первых, найм живёт по законам рынка, а не по законам SLA.

Сколько бы ни хотелось написать «закрываем вакансию за 21 день», реальность диктуют спрос на редкие навыки, конкуренция за кандидатов и цикл принятия решений. Здесь платформа и процесс помогают прозрачно видеть воронку и сроки, но не превращают поиск Java‑разработчика в тикет, который всегда закрывается по регламенту. На найм можно заводить заявки, считать метрики и строить прогнозы, но нельзя заставить рынок подчиняться внутреннему SLA.

• Во‑вторых, увольнение и сложные кейсы никогда не будут просто тикетом.

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

• В‑третьих, не всё в HR вообще можно сделать сервисом.

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

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

В итоге идея такая: не пытаться превратить HR в ещё один Service Desk, а дать HR сервисные инструменты, чтобы навести порядок там, где это действительно мешает людям и бизнесу.

***

В каких HR‑процессах у вас сегодня больше всего «ручного ада» — онбординг, переводы, обучение или что‑то другое?