Как мы построили сквозной HR-модуль: от заявки на найм до выхода сотрудника

В большинстве растущих компаний HR-процессы выглядят одинаково.

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

Статусы вакансий — «где-то у кого-то».

Формально процесс существует. Фактически — он не управляется.

У нас было ровно так же. Пока мы не решили собрать весь цикл подбора в единый цифровой контур и не построили сквозной HR-модуль внутри нашей платформы.

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

Как HR вырос из системы планирования

Dynamic Roadmap Planner изначально не задумывался как HR-система.

Мы создавали инструмент финансового прогнозирования и дорожных карт развития проектов — для приоритизации, управляемости и расчёта сценариев.

Но довольно быстро стало понятно: точность планирования упирается не только в финмодели и roadmap-логику. На результат напрямую влияют:

• найм и скорость закрытия позиций
• загрузка команд
• подрядчики и партнёры
• договоры
• операционные процессы

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

Так вместо набора отдельных инструментов начала формироваться связанная цифровая среда процессов.

Сегодня в платформе между собой связаны:

• договоры
• клиенты и лиды
• партнёры
• финансы и прогнозирование
• проектное планирование
• дорожные карты
• OKR-система
• события и действия пользователей

Поверх этого мы добавили сквозные комментарии, уведомления, аудит действий и лёгкую геймификацию — всё на общей архитектурной базе.

Комментарии и уведомления мы не реализовывали с нуля: переиспользовали готовые микросервисы, ранее разработанные для платформы AIINS. Это позволило ускорить внедрение, сохранить единый пользовательский опыт и не раздувать техническую сложность решения.

Почему HR пришлось делать частью системы, а не отдельным инструментом

В какой-то момент рост команды стал упираться не в количество кандидатов, а в управляемость найма.

Подбор начал напрямую влиять на:

• сроки проектов,
• финансовые прогнозы,
• загрузку команд,
• достижение целей и OKR.

HR перестал быть «вспомогательной функцией» и стал критическим элементом планирования.

Поэтому мы сразу проектировали его не как изолированную HR-систему, а как часть общей доменной модели платформы.

Я отвечаю за весь проект Dynamic Roadmap Planner в целом — от архитектуры и продуктовой логики до реализации и внедрения. HR-модуль стал одним из ключевых контуров, за который я также нёс полную ответственность на всех этапах.

Как теперь выглядит процесс найма

Вместо набора несвязанных действий мы выстроили непрерывную цепочку сущностей и состояний:

заявка на найм → вакансия → кандидаты → оффер → сотрудник

Это дало несколько принципиальных эффектов:

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

Процесс перестал быть набором ручных операций и стал управляемым потоком.

Что мы реализовали на практике

Заявки на найм

Руководитель создаёт заявку с ключевыми параметрами:

• роль
• условия
• бюджет
• причина найма (рост / замена / стажёр)

Мы встроили маршрут согласования по управленческой иерархии.

После согласования вакансия создаётся из заявки одной кнопкой — без повторного ввода данных.

Вакансии

Вакансия — это не просто карточка, а полноценный рабочий контур подбора:

• профиль позиции
• этапы отбора
• бюджет публикаций
• связь с заявкой
• воронка кандидатов
• метрики в реальном времени
• аналитика и статистика по вакансии (этапы, источники, сроки)

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

Кандидаты

Карточка кандидата создаётся один раз и используется во всех вакансиях.

В ней хранится:

• история откликов
• этапы
• заметки
• решения
• коммуникации

Мы добавили несколько способов быстрого ввода:

• загрузка резюме (PDF / Word)
• автоматический парсинг
• импорт по ссылке hh
• ручное создание

Это существенно сократило время первичной обработки кандидатов.

Офферы

Оффер — отдельная доменная сущность, которая живёт по собственному жизненному циклу и связана с заявкой на найм и кандидатом.

В оффере фиксируются:

• условия предложения
• ответственные лица по заявке
• маршрут согласования
• таймлайн движения оффера

Согласование оффера происходит в рамках заданного маршрута, а все изменения и решения сохраняются в истории.

После принятия оффера система автоматически:

• фиксирует дату выхода
• создаёт карточку сотрудника
• закрывает заявку на найм

Без ручных переносов между системами и документами.

Испытания и стажировки

Тестовые задания и стажировки встроены в общий процесс:

• сроки
• результаты
• оценки
• комментарии

Эти этапы участвуют в аналитике и таймлайне кандидата наравне с остальными.

Автоматизации, которые дали реальный эффект

Моя ключевая задача как руководителя разработки была не просто «оцифровать формы», а убрать ручную операционную нагрузку и сделать процесс масштабируемым.

Мы внедрили:

• автоматические согласования по иерархии
• авто-одобрение в допустимых сценариях
• сервис парсинга резюме (PDF, Word, OCR-сканы)
• импорт кандидатов по ссылке hh
• автосоздание сотрудника из принятого оффера
• автопереход статуса «вышел на работу» по дате
• живую аналитику по вакансиям и этапам

Всё это встроено в процесс и не требует дополнительного обслуживания со стороны HR.

Отдельно мы заложили контроль SLA по подбору: целевые сроки закрытия вакансий и прохождения этапов.

Система считает фактическое время найма, конверсию этапов и динамику движения кандидатов — позволяя видеть отклонения не постфактум, а в моменте.

Что изменилось на практике

Для HR

• меньше рутины
• быстрее работа с кандидатами
• единая история взаимодействий
• прозрачные согласования
• меньше ручных ошибок
• контроль сроков этапов (SLA)

Для руководителей

• статус найма виден в любой момент
• контроль сроков и бюджета
• понятная воронка по каждой позиции
• видимость узких мест
• прогнозируемость сроков закрытия вакансий

Для компании

• управляемый процесс подбора
• цифровой след решений
• объективная аналитика найма
• связь HR с планированием, финансами и OKR
• масштабируемость без роста ручной нагрузки

Архитектурные принципы

При проектировании платформы и HR-контура в частности я фокусировался на:

• связной доменной модели
• событийной логике статусов
• отказе от дублирования данных
• расширяемости процессов
• ролевой модели доступа
• аудите действий

Дополнительно были встроены:

• разграничение прав
• аудит ключевых операций
• комментарии и уведомления
• лёгкая геймификация активности

Вывод

В этой статье я разобрал HR-контур подбора персонала как один из ключевых элементов Dynamic Roadmap Planner. Но он является частью более широкой экосистемы — финансового прогнозирования, OKR-системы, договорного контура, проектного планирования и связанной событийной модели.

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