Материал завершает серию статей о build vs buy в HRTech.
В этой статье я попробую собрать оптимальный подход к созданию HR‑платформы, при котором:
- с нуля разрабатывается то, что делает компанию уникальной, требует глубокой интеграции, формирует единое пространство данных и единый пользовательский опыт;
- с рынка берётся то, что уже стало зрелым прикладным решением и где ценность собственной разработки ниже, чем риски её создания.
То есть в основе лежит смешанный подход как наиболее универсальный вариант, позволяющий осознанно взять лучшее из двух миров.
При этом:
- мы никогда не забываем об интеграции, чтобы данные передавались быстро и без ошибок, поддерживая сквозные процессы и аналитику;
- мы кастомизируем пользовательский интерфейс, чтобы обеспечить нужный пользовательский опыт.
В идеале сотрудник вообще не должен понимать, в какой именно системе он работает: для него это всё — единая корпоративная HR‑платформа с общим интерфейсом.
Как одна и та же музыка по-разному звучит в разных помещениях, так и предложенный подход будет иметь свои нюансы в разных компаниях, но я постарался подобрать классическое «звучание» для большинства крупных enterprise‑компаний.
Сборка решений для платформы
Ниже — пример целевой сборки HRTech‑платформы для крупной enterprise‑компании. Это не универсальный рецепт, а базовая конфигурация, в которой для каждого класса решений выбрано своё положение на шкале build vs buy. Где-то рациональнее использовать зрелый рыночный продукт, где-то — строить собственный платформенный слой, а где-то — комбинировать оба подхода.
1. Talent Marketing Platform
Рекомендация: брать с рынка, при необходимости кастомизируя интерфейс карьерного сайта, если он является частью бренда работодателя или активно используется как витрина вакансий для внутренних переходов.
Почему:
- карьерные сайты, лендинги и формы отклика уже хорошо реализуются готовыми инструментами, которые активно развивались в последние годы;
- такой функционал часто поставляется в связке с ATS + CRM Candidate.
Примеры: Potok, Huntflow, Talantix и др.
Когда писать своё:
- если нужен сильно кастомизированный карьерный портал;
- если необходимо обеспечить единый опыт кандидата в рамках внутренней мобильности и работы с реферальными программами;
- если подбор — ключевое конкурентное преимущество компании с уникальными механиками и этот блок вместе с ATS + CRM Candidate нужно закрывать собственной разработкой.
2. ATS + CRM Candidate
Рекомендация: брать с рынка, при необходимости создавая кастомный кабинет для нанимающего менеджера внутри интерфейса управления командой.
Почему:
- ATS — зрелый класс решений, который особенно активно развивался в последние годы, в том числе с использованием ИИ;
- вероятно, это развитие будет продолжаться, а обновления от вендора останутся полезными.
Примеры: Potok, Huntflow, Talantix и др.
Когда писать своё:
- если у компании экстремально сложный массовый найм;
- если нужен единый контур внешнего и внутреннего найма;
- если рекрутмент — ключевое конкурентное преимущество бизнеса.
3. Assessment Hub
Рекомендация: писать своё, при этом обеспечив возможность интеграции с внешними центрами оценки в случаях, когда опросник и методология являются интеллектуальной собственностью подрядчика.
Почему:
- единая модель навыков, сценарии оценки кандидатов и сотрудников, а также связь результатов с Performance / LXP / Career требуют глубокой интеграции в платформу;
- этот блок часто требует собственной логики и тесной связи с другими HR-процессами;
- для сотрудника и менеджера важно обеспечивать консистентный пользовательский опыт в рамках единого интерфейса.
4. Offer & Contract Management
Рекомендация: писать своё, но переиспользуя механизмы генерации, согласования, подписания и хранения документов из других процессов. Иными словами, создавать этот блок на базе общего решения по работе с документами (КЭДО) и механизма согласований.
Почему:
- есть тесная связь с процессами Compensation Management и Org Design;
- нужна единая база маршрутов согласования, ответственных и замещающих на время отпусков, командировок, больничных и других отсутствий;
- важен единый to-do-лист по HR-задачам;
- связка с ATS, КЭДО, проверками, кадровыми событиями и безопасностью часто оказывается очень специфичной.
5. Onboarding Experience
Рекомендация: писать своё.
Почему:
- адаптация закладывает основы пользовательского опыта сотрудника во всей HR-платформе;
- онбординг — это не просто отдельный процесс, а точка входа в компанию и в цифровую среду работодателя;
- этот блок не только включает собственные сценарии, но и запускает, координирует, а затем агрегирует результаты множества других HR-процессов внутри платформы: документы, доступы, обучение, задачи, цели и др.;
- для сотрудника, руководителя и смежных функций особенно важны единый интерфейс, единая логика шагов и прозрачный статус прохождения.
6. Core HR
Рекомендация: брать с рынка как систему для кадрового учёта, минимизируя кастомизацию ядра и встраивая её в общий платформенный контур.
Почему:
- Core HR — это прежде всего контур кадрового учёта, где критичны точность, надёжность и соответствие локальному законодательству;
- этот класс решений сильно зависит от законодательных требований и требует постоянной адаптации к изменениям;
- цена ошибки здесь особенно высока: некорректные кадровые данные влияют на документы, статус сотрудника, расчёты и отчётность;
- на рынке давно сложились стандарты кадрового учёта и класс систем, отвечающих за него.
Примеры решений: 1С:ЗУП / 1С:ЗУП КОРП, БОСС-Кадровик, Галактика, Парус.
Исключение: собственная разработка может быть оправдана только для очень крупных компаний с большим масштабом как один из способов преодолеть технические ограничения решений, доступных на рынке после ухода SAP HR, в первую очередь ограничения масштабирования в рамках единой базы.
7. Workforce Administration
Рекомендация: брать с рынка в едином контуре с Core HR.
Почему:
- Workforce Administration в российском контексте обычно тесно связан с Core HR и редко имеет смысл как отдельный самостоятельный контур;
- сюда входят наиболее чувствительные и рискованные процессы: кадровые операции, табель, графики, начисления, льготы, налоги, расчёты и регуляторная отчётность;
- этот блок сильно зависит от локального законодательства и требует постоянного сопровождения изменений;
- цена ошибки здесь максимальна: неверные расчёты, нарушения требований регулятора, штрафы, претензии сотрудников и риски для финансового контура;
- на рынке давно сложились зрелые практики и стандарты для этого класса систем.
Примеры решений: 1С:ЗУП / 1С:ЗУП КОРП, БОСС-Кадровик, Галактика, Парус.
Исключение: собственная разработка может быть оправдана только для очень крупных компаний с большим масштабом как один из способов преодолеть технические ограничения решений, доступных на рынке после ухода SAP HR, в первую очередь ограничения масштабирования в рамках единой базы.
8. Performance Management
Рекомендация: писать своё.
Почему:
- Performance Management — один из ключевых инструментов повышения эффективности компании через повышение эффективности сотрудников;
- коробочное решение лучше, чем отсутствие решения как такового, однако компания, которая стремится не просто следовать рыночным практикам, а опережать рынок, должна формировать собственную модель управления эффективностью на базе лучших практик, а технологическая платформа должна обеспечивать её реализацию;
- этот блок требует качественного пользовательского опыта и глубокой интеграции в сквозные процессы HR-платформы.
9. Employee Profile Hub
Рекомендация: писать своё.
Почему:
- единый профиль сотрудника — одна из ключевых основ платформенного подхода;
- здесь консолидируются мастер-данные, формируется «золотая запись», а также хранятся роли, атрибуты, история, навыки, статусы и связи со всеми модулями платформы;
- этот блок обеспечивает целостность данных, сквозную интеграцию процессов и единый контекст для всех HR-сценариев.
10. Learning Experience Platform (LXP)
Рекомендация: брать с рынка как базовый инструмент доставки образовательного контента, дополняя его собственной надстройкой для управления обучением, рекомендациями и интеграцией в HR-процессы.
Современный сценарий обучения требует не только удобного доступа к контенту, но и возможности поддерживать обучение just in time или даже проактивно — на основе анализа компетенций, роли, контекста и задач, стоящих перед сотрудником. Поэтому оптимальный подход — использовать рыночное решение как инфраструктурную основу, а дифференцирующую логику рекомендаций, оркестрации и встраивания в сквозные HR-процессы реализовывать в собственном платформенном слое.
Почему:
- LXP — зрелый класс решений, который хорошо закрывает базовые сценарии доставки образовательного контента: каталоги, треки, тесты, проигрыватели курсов, SCORM, личные кабинеты и базовый пользовательский опыт;
- базовый функционал LXP в значительной степени стандартизирован и широко доступен в готовых рыночных продуктах;
- разработка собственного LXP-ядра обычно не даёт сопоставимого конкурентного преимущества, но требует существенных затрат на создание и дальнейшее сопровождение.
Примеры решений: Websoft HCM / WebTutor, Mirapolis LMS, iSpring Learn и др.
11. Employee Engagement
Рекомендация: брать с рынка.
Почему:
- опросы, pulse surveys, eNPS, сегментация и типовые дашборды относятся к прикладным и хорошо стандартизированным решениям;
- разрабатывать такой функционал с нуля обычно имеет смысл только в двух случаях: если это позволяет существенно экономить на лицензиях или если остальной HR-контур уже преимущественно построен на собственной разработке;
- основная ценность в этом классе решений создаётся не в механике проведения опросов, а в последующих управленческих действиях на основе полученной обратной связи.
Примеры решений: Happy Job, ЭКОПСИ, Websoft и др.
12. Talent & Succession Planning
Рекомендация: писать своё.
Почему:
- формально базовую функциональность этого блока можно приобрести в составе рыночных решений; при этом его ключевые пользовательские механики, как правило, относительно просты и воспроизводимы — кадровый резерв, 9-box и т.д.;
- при этом сами процессы управления талантами и преемственностью почти всегда глубоко завязаны на внутреннюю HR-модель, критерии оценки потенциала, карьерные сценарии, управленческие роли и культуру принятия кадровых решений;
- в результате основная сложность возникает не в реализации базовых механик, а во встраивании их во внутреннюю среду компании, сквозные HR-процессы и управленческую практику;
- для компании с развитой собственной HR-моделью часто рациональнее реализовать этот блок в собственной платформе, чем адаптировать под себя логику внешнего решения.
13. Career & Mobility Hub
Рекомендация: писать своё.
Почему:
- Career & Mobility Hub — это не просто витрина внутренних вакансий, а один из ключевых драйверов повышения эффективности компании за счёт более полного использования внутреннего кадрового потенциала;
- этот контур требует глубокой связки с профилем сотрудника, вакансиями, навыками, обучением, Performance Management и Talent & Succession Planning;
- внедрение этого блока требует не только автоматизации процессов, но и изменения управленческих практик и мышления руководителей и сотрудников: внутренние переходы должны становиться прозрачными, формализованными и управляемыми, а не оставаться результатом кулуарных договорённостей;
- готовые решения на российском рынке редко представлены как самостоятельный и зрелый процесс, поскольку наибольшую ценность он обычно имеет в крупных компаниях за счёт масштаба, а само направление пока остаётся относительно новым для российского HR-рынка.
14. Offboarding & Alumni Network
Рекомендация: писать своё, переиспользуя существующие решения для КЭДО, workflow и управления процессами.
Почему:
- offboarding — это в значительной степени стандартный процесс, состоящий из workflow, интеграций, документооборота, обходных листов и опросов, поэтому нет смысла разрабатывать все его компоненты с нуля;
- при этом в собственной HR-платформе этот блок может стать не только процессом выхода, но и инструментом удержания: система может выявлять предпосылки увольнения, определять нежелательные для бизнеса потери и предлагать альтернативные сценарии, включая внутренние переходы через Career & Mobility Hub;
- alumni network имеет смысл только как продолжение реальной корпоративной культуры и сильного HR-бренда; в противном случае стандартное решение рискует остаться формальной, но не живой функциональностью.
15. Org Design & Workforce Planning Platform
Рекомендация: писать своё.
Почему:
- оргдизайн и workforce planning в высокой степени зависят от специфики бизнеса, организационной структуры, модели управления, производственного контура и логики планирования ресурсов;
- типовые решения на рынке часто либо покрывают только базовые сценарии, либо слабо интегрируются с внутренними HR-, финансовыми и операционными процессами компании;
- особую ценность такой контур имеет для холдингов, производственных, территориально распределённых и организационно сложных компаний, где требуется моделировать структуру, численность, роли, подчинённость и сценарии изменений;
- если компании достаточно коробочного решения, то её потребность, как правило, остаётся на уровне Core HR и базового кадрового администрирования, без необходимости в глубоком организационном моделировании и продвинутом workforce planning.
16. Compensation & Rewards Management
Рекомендация: писать своё, при необходимости переиспользуя отдельные компоненты для расчётов, документооборота и аналитики.
Почему:
- compensation & rewards напрямую связаны с HR-стратегией, организационной структурой, performance management, грейдами, бюджетированием и политиками компании, поэтому редко хорошо укладываются в типовое коробочное решение без значительной адаптации;
- в этой области особенно важны гибкость правил, поддержка разных моделей вознаграждения, сценарное моделирование, бюджетный контроль, согласовательные процессы и прозрачная управленческая аналитика;
- наибольшую ценность собственная платформа даёт крупным компаниям и холдингам, где compensation-процессы тесно связаны с эффективностью бизнеса, удержанием ключевых сотрудников, внутренней справедливостью и управлением фондом оплаты труда;
- если компании достаточно коробочного решения в этом контуре, это обычно означает, что её потребность ограничивается базовым администрированием компенсационных процессов, без глубокой кастомизации, сложной логики и стратегического управления.
17. People Analytics Platform
Рекомендация: писать своё, используя рыночные BI-инструменты.
Почему:
- People Analytics требует единого слоя данных, который должен принадлежать компании и формироваться внутри её платформенного контура;
- готовые отчёты вендоров почти всегда ограничены рамками конкретного модуля и плохо отвечают на сквозные управленческие вопросы;
- реальная ценность аналитики возникает на стыке всех HR-модулей, финансовых, операционных и других бизнес-данных;
- именно собственная аналитическая платформа позволяет выстраивать единую модель метрик, рассчитывать кастомные показатели, строить прогнозы и обеспечивать управленческую интерпретацию данных в логике конкретного бизнеса.
18. HR Automation Engine
Рекомендация: писать своё, но на базе готовых технологических платформ.
Почему:
- это фундамент, который позволяет превратить гибридную модель из «лоскутного одеяла» в единую HR-платформу;
- именно этот слой связывает между собой отдельные решения — как покупные, так и самописные, — сшивая их сквозными end-to-end-процессами;
- здесь реализуются orchestration-логика, маршрутизация задач, правила принятия решений, интеграционные сценарии, статусы процессов, уведомления и контроль исполнения;
- без такого слоя даже хорошие отдельные решения будут оставаться набором разрозненных систем, а не единой платформой;
- поэтому оптимальный подход — не создавать всё с нуля на низком технологическом уровне, а опираться на готовые BPM / workflow / low-code-платформы, поверх которых строится собственная бизнес-логика компании.
Можно смотреть платформы: ELMA365, Camunda, BPMSoft и др.
Итог
В итоге идеальное «звучание» HRTech‑платформы возникает не тогда, когда компания выкручивает все регуляторы на максимум в сторону собственной разработки или, наоборот, полностью уходит в покупные решения. Оно появляется тогда, когда каждый HR‑продукт настроен в оптимальном диапазоне под задачи конкретной компании.
При этом сам вопрос покупать или делать самими намного глубже выбора подхода к созданию ИТ решения. Компании выбирают не просто ИТ‑решение, а модель собственной HR‑трансформации.
Ставить запятую в фразе «разработать нельзя купить» нужно не исходя из моды, обещаний вендоров или веры в магию собственной разработки, а исходя из трезвой оценки масштаба компании, зрелости HR и ИТ, стоимости владения, требований к данным, интеграции и пользовательскому опыту. И чем честнее компания ответит себе на эти вопросы в начале пути, тем меньше вероятность, что цифровая трансформация превратится в дорогой и затяжной компромисс с постоянными перезапусками и поиском виноватых — вместо создания реальной HR‑платформы, которая помогает сотрудникам и даёт эффект бизнесу.
Подписывайтесь, комментируйте — продолжение обязательно будет