Добавить в корзинуПозвонить
Найти в Дзене
Пилигрим: путь в HRTech

Архитектура HRTech

Материал входит в серию статей о build vs buy в HRTech. При обсуждении HRTech легко свести разговор к выбору конкретных систем. Но устойчивость HRTech-ландшафта определяется не набором внедрённых решений как таковых, а тем, как они связаны между собой. Именно архитектура отвечает на вопрос, станет ли HRTech в компании единой платформой или останется совокупностью разрозненных инструментов, каждый из которых решает локальную задачу, но не формирует целостный пользовательский и управленческий контур. Это особенно важно в HR-домене, где почти ни один процесс не существует изолированно. Найм связан с адаптацией, адаптация — с обучением, обучение — с эффективностью, эффективность — с карьерным развитием, компенсациями и удержанием. Если между этими этапами нет общего пространства данных, сквозной логики маршрутизации и единого пользовательского опыта, компания неизбежно сталкивается с дублированием информации, потерей контекста, ручными передачами между системами и фрагментированным опытом
Оглавление

Материал входит в серию статей о build vs buy в HRTech.

При обсуждении HRTech легко свести разговор к выбору конкретных систем. Но устойчивость HRTech-ландшафта определяется не набором внедрённых решений как таковых, а тем, как они связаны между собой. Именно архитектура отвечает на вопрос, станет ли HRTech в компании единой платформой или останется совокупностью разрозненных инструментов, каждый из которых решает локальную задачу, но не формирует целостный пользовательский и управленческий контур.

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

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

4 ступени и платформа построения HRTech
4 ступени и платформа построения HRTech

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

Архитектура HRTech
Архитектура HRTech

6 слоёв HRTech-архитектуры

1. Общий слой UX/UI сотрудника

Верхний слой — это единая пользовательская оболочка платформы. Он отвечает за то, как сотрудник, кандидат, менеджер или HR-специалист взаимодействует со всеми сервисами. Сюда входят единая точка входа, self-service-сценарии, уведомления и оповещения, персонализированный интерфейс и список задач.

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

2. Слой управления процессами

Ниже расположен слой, в первую очередь отвечающий за оркестрацию процессов. Это процессный движок платформы, который обеспечивает no-code-автоматизацию HR-процессов, маршрутизацию задач, согласования, управление статусами, событийные сценарии и интеграцию между модулями.

Этот слой критически важен, потому что именно он превращает набор отдельных компонентов в работающие end-to-end процессы. С ним платформа может поддерживать сквозные сценарии: например, переводить кандидата из ATS в оформление оффера, затем в preboarding, далее — оформление, обучение, развитие и внутреннюю мобильность.

3. Слой бизнес-логики

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

3.1. Привлечение и найм

Этот контур закрывает функционал внешнего входа в компанию. В него входят:

  • Talent Marketing Platform;
  • ATS + CRM Candidates;
  • Offer & Contract Management;
  • Assessment Hub.

Здесь сосредоточены сценарии взаимодействия с рынком кандидатов, управление воронкой найма, оценка, коммуникации, подготовка и согласование предложения о работе.

3.2. Ядро HR

Это операционная основа платформы, включающая:

  • Core HR;
  • Workforce Administration.

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

3.3. Развитие и эффективность

Этот блок включает в себя управление результативностью и развитием сотрудников. В него входят:

  • Performance Management;
  • Learning Experience Platform (LXP);
  • Talent & Succession Planning;
  • Career & Mobility Hub.

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

3.4. Опыт сотрудника

Этот контур отвечает за качество взаимодействия сотрудника с компанией на протяжении всего жизненного цикла. В него входят:

  • Onboarding Experience;
  • Employee Engagement;
  • Offboarding & Alumni Network.

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

4. Слой единого профиля сотрудника

Под прикладными модулями расположен Employee Profile Hub — один из ключевых платформенных компонентов. Он формирует единый цифровой профиль сотрудника и выступает точкой консолидации данных из разных HR-модулей.

К его функциям относятся:

  • консолидация HR-данных;
  • работа со справочниками и первоисточниками;
  • формирование «золотой записи» о сотруднике;
  • обеспечение связи между всеми HR-модулями;
  • поддержка единого источника правды.

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

5. Слой организационных данных

Ниже расположен слой организационного контекста, который задаёт структуру компании и правила управления рабочей силой. Он включает:

  • Org Design & Workforce Planning Platform;
  • Compensation & Rewards Management.

Этот слой содержит и предоставляет другим слоям платформы данные о таких сущностях, как организационная структура, роли, подразделения, должности, компетенции, планы численности, грейды, компенсации, бонусы и системы мотивации. Также он может включать процессную модель компании в целом, а не только HR-процессы. Он особенно важен для зрелых HR-платформ, потому что связывает HR-процессы не только с человеком как единицей учёта, но и с организацией как управляемой системой.

6. Сквозной аналитический слой

Нижний слой архитектуры — People Analytics Platform. Он обеспечивает сбор и объединение HR-данных, отчётность, дашборды, анализ эффективности процессов, прогнозирование и поддержку принятия решений.

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

Как работают связи между слоями

Логика архитектуры не строго иерархическая, а сквозная.

  • Пользовательский слой обеспечивает единый вход и единый пользовательский опыт.
  • Процессный слой оркестрирует процессы и связывает отдельные модули между собой.
  • Бизнес-модули реализуют конкретную HR-функциональность.
  • Employee Profile Hub объединяет модули вокруг единых данных о сотруднике, кандидате и бывшем сотруднике.
  • Организационный слой добавляет контекст структуры, ролей и модели вознаграждения.
  • Аналитический слой собирает данные со всех уровней, формирует обратную связь и поддерживает управленческие решения.

Именно такая конфигурация позволяет платформе быть не просто функционально полной, а архитектурно целостной.

Почему эта модель полезна в контексте build vs buy

Эта схема позволяет обсуждать build vs buy не только как выбор отдельных продуктов, закрывающих отдельные участки бизнес-логики, а как выбор способа построения каждого слоя архитектуры, чтобы в результате получить HR-платформу, а не набор решений.

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

Да и, как я писал ранее, часто в первую очередь важнее определиться не с того, как что-то строить, а с того, что именно строить.

Подписывайтесь, комментируйте — продолжение обязательно будет