HRTech: Разработать нельзя купить

К читателю

Некоторое время назад я решил набросать небольшую статью, обыгрывающую известную фразу «Казнить нельзя помиловать», в которой хотел ответить на вопрос build vs buy в HRTech. Но в свойственной себе манере увлёкся и получил longread более 50 тыс. знаков, что нарушает все возможные принципы блогинга.

Поэтому я решил разбить исходный материал на серию статей, которых получилось целых 10. Работая над ними, я часто углублялся в проработку отдельных тем, отчего материал только разрастался. Сейчас же я решил собрать получившиеся наработки в единую «режиссёрскую версию», которая приближается уже к 100 тыс. знаков.

Это уже скорее не просто ответ на вопрос build vs buy в HRTech, а попытка подробно разобрать проблематику создания такой системы в целом.

Если найдётся смельчак, который сможет дочитать статью до конца, прошу: найди ещё несколько минут и поделись впечатлением.

Предисловие

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

Контекст

Многое в этом мире подвержено колебаниям, и HRTech — не исключение. Рынок склонен сначала очаровываться очередной большой идеей, а затем разочаровываться в ней — иногда даже по причинам, не связанным с самой идеей напрямую. На смену одному подходу приходит противоположный, и цикл повторяется.

Если смотреть ретроспективно на российский рынок, то начало 1990‑х можно назвать временем собственных разработок, а 2000‑е — эрой «коробочных» решений, которые многим казались окончательной победой. Однако ограничения таких решений, даже если они были основаны на наборе лучших практик, со временем становились всё заметнее. Переход к облачным моделям ещё сильнее подчеркнул эти ограничения. В результате к концу 2010‑х рынок снова начал смещаться в сторону собственных платформ.

В начале 2020‑х этот поворот окончательно закрепился: многие компании реального сектора стали трансформироваться в tech‑компании и создавать ИТ‑дочки для развития собственных платформенных решений. После шока начала 2022 года и ухода западных вендоров с опустевшего рынка эта тенденция только усилилась.

Моё мнение: сейчас рынок снова находится на распутье. С одной стороны, накапливается разочарование в собственной разработке, а на рынке появляются новые игроки с громкими обещаниями непревзойдённого качества. С другой стороны, AI и low-code, которые, вероятно, радикально изменят индустрию разработки, смещают фокус выбора от прикладного продукта к среде разработки.

Почему возникает разочарование в собственной разработке

Ваши ожидания — ваши проблемы, и в этом плане мало что изменилось со времён матча на Евро‑2012. Бизнес часто ждёт от tech «серебряной пули», способной решить все проблемы. Сначала эти надежды возлагались на коробочные решения с набором лучших практик, затем — на собственные разработки.

Компании пытаются решить проблемы незрелых внутренних процессов с помощью технологий. Не наведя порядок в процессах и не приняв сложных управленческих решений, они сначала пытаются «натянуть сову на глобус», ломая архитектуру и логику выбранного решения. А затем, не сделав организационных выводов, переносят те же самые процессы в собственную разработку.

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

Не стоит недооценивать и другой источник разочарования: романтизацию собственной разработки. Многие компании с энтузиазмом открывают tech‑офисы, покупают кофемашины, выстраивают модный внешний контур и на какое-то время начинают чувствовать себя чем-то средним между Apple и Google. Но довольно быстро выясняется, что собственная разработка — это не только эстетика технологичности, но и тяжёлая производственная рутина. Это не разовый проект, а постоянный цикл найма, приоритизации, конфликтов между бизнесом и ИТ, накопления техдолга, сопровождения legacy, интеграций, инцидентов и бесконечных доработок. И когда первая волна энтузиазма проходит, многие обнаруживают, что построили не «ИТ своей мечты», а дорогое и трудноуправляемое производство, которое требует всё больше ресурсов. В этот момент разговоры о технологической независимости часто сменяются разговорами о сокращении костов и переосмыслении роли ИТ.

Но, как и в разводе, где обычно виноваты оба, так и здесь: tech сам оказался не вполне готов к такому взрывному интересу к разработке собственных решений. За последние годы существенно выросли требования к программному обеспечению, его дизайну и пользовательскому опыту, а сами технологии заметно усложнились. То, что раньше могли реализовать несколько разработчиков, теперь требует в разы больше ресурсов.

Изменились и сами ресурсы. Если раньше программистами, как правило, становились выпускники профильных технических вузов с сильной инженерной базой, заложенной ещё советской технической школой, то теперь у многих за плечами ускоренные курсы по востребованным языкам программирования. AI и low-code могут стать одним из ответов на эти вызовы: они способны сократить потребность в технических ресурсах и сместить фокус на компетенции в более прикладных областях.

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

Что на самом деле нужно бизнесу от tech

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

Именно поэтому главный запрос сейчас — не на очередную технологическую моду и не на новую «серебряную пулю». AI и low-code — лишь инструменты, которые могут частично закрыть проблему дефицита ресурсов и освободить tech от части технической рутины. Их настоящая ценность в другом: они дают шанс сместить фокус на гораздо более дефицитные компетенции — понимание бизнеса, продуктовое мышление и способность принимать решения на стыке бизнеса и ИТ.

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

Команда

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

Продуктовый vs проектный подход

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

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

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

Не говоря уже о классических проектных рисках, которые похожи на чеховское ружьё: о них все знают, к ним готовятся, но в итоге они всё равно выстреливают.

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

Продуктовая команда

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

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

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

Команда — это не набор аккуратно разложенных по полкам специалистов, а среда, в которой люди работают на общий результат, а не только на собственный участок. И это давало гораздо больше, чем просто взаимовыручку. У каждого постепенно появлялась более широкая экспертиза. Люди начинали понимать и HR-, и ИТ-логику, видеть не только потребности одной стороны, но и ограничения другой. В итоге решения получались сильнее именно потому, что обе перспективы учитывались с самого начала, а не сталкивались потом лоб в лоб.

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

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

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

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

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

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

Состав команды

Вынося роль Product Owner за скобки, попробую описать актуальную ролевую модель типовой команды.

Старт

В современных реалиях ядро команды разработки пользовательского приложения — а именно из таких решений в значительной степени и состоит HRTech — невозможно без трёх ролей:

• frontend-разработчика,
• backend-разработчика,
• UX/UI-дизайнера.

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

Если не рассматривать low-code-разработку, то необходимость frontend- и backend-разработчиков очевидна уже на этапе работы над MVP. С дизайном это не всегда кажется столь же очевидным — но, на мой взгляд, зря.

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

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

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

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

Рост

DevOps. Независимо от способа использования инфраструктуры, вам довольно рано понадобится DevOps. Даже внутри облачной среды кто-то должен развернуть и поддерживать ваши окружения: разработку, тестирование, demo, pre-prod, production и другие. Их набор может отличаться в зависимости от зрелости продукта и принятых правил разработки, но очень быстро становится понятно: одной среды недостаточно.

Это неизбежно. Вам нужно где-то показывать продукт пользователям, пока команда продолжает работу. Нужно где-то проверять изменения до выхода в production. Нужны бэкапы, мониторинг, логи, доступы, процессы поставки и восстановления. Это отдельный мир.

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

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

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

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

Мой совет — не откладывайте неизбежное. Берите QA, чтобы с самого начала выстраивать процесс тестирования параллельно с процессом разработки. И сразу закладывайте автотесты: они сильно помогают с регрессией.

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

Спорные роли

Я бы выделил три спорные для себя роли в команде:

• Project Manager / Delivery Manager / Scrum Master
• Tech Lead
• Системный и/или бизнес-аналитик

Сами по себе эти роли не спорны. Наоборот, соответствующие компетенции полезны и нередко необходимы. Вопрос в другом: всегда ли под них нужен отдельный человек?

Project Manager / Delivery Manager / Scrum Master. Здесь я объединяю роли, отвечающие за организацию работы внутри команды и за поставку результата. Чем сложнее внешняя среда — процессы, согласования, зависимости, ожидания менеджмента, — тем больше у этой роли реальной работы и тем выше ценность выделенного человека.

Если такого человека нет, эти задачи никуда не исчезают. Они просто начинают оседать на Product Owner и других участниках команды. В результате Product Owner быстро превращается из владельца продукта в диспетчера процессов.

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

Tech Lead. У появления роли Tech Lead обычно есть несколько предпосылок. Первая — слабая техническая экспертиза у отдельных участников команды на фоне отсутствия сильного экспертного сообщества в ресурсном пуле. Тогда этот дефицит компенсируют выделением отдельного эксперта внутри команды. Вторая — ситуация, когда senior-разработчик перерастает свою текущую позицию, и для того чтобы удержать его внутри компании, под него фактически создают новую роль.

Для меня это, пожалуй, самая непонятная роль в команде. Не потому, что техническое лидерство не нужно, а потому, что не всегда понятно, должен ли для него существовать отдельный человек.

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

Отдельная проблема этой роли в том, что часто непонятна сама граница ответственности. Это всё ещё tech, и человек должен непосредственно участвовать в разработке? Или это уже lead, и его основная задача — координировать, направлять и принимать технические решения? На практике эта размытость регулярно создаёт путаницу и по ожиданиям, и по зоне ответственности.

И, наверное, самый плохой сценарий — когда из отличного senior-разработчика получается слабый Tech Lead. В этом случае команда теряет сильного разработчика, но при этом не получает полноценного лидера.

Системный и/или бизнес-аналитик. Как для практикующего Product Owner, это, пожалуй, одни из самых противоречивых ролей в команде.

С одной стороны, вместе с UX/UI-дизайнером это одни из главных помощников Product Owner в развитии продукта. Часто его единомышленники. Без их участия при работе над большим продуктом очень быстро перестаёт хватать времени: просто в сутках уже недостаточно 24 часов. Особенно если в компании действует производственный framework, который жёстко регламентирует состав и объём документации, разрабатываемой командой.

С другой стороны, эти роли легко могут превратиться в лишнюю прослойку между Product Owner и командой разработки. В таком случае аналитик либо начинает работать как «испорченный телефон», либо постепенно приучает разработчиков не думать самостоятельно, перекладывая всю ответственность на спецификацию.

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

Другие роли

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

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

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

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

Вероятно, параллельно с этим будет происходить и постепенная стандартизация самой роли. Вполне возможно, что скоро такая компетенция станет востребованной уже на самых ранних этапах развития продукта. И если когда-то Scrum Master помогал команде осваивать Scrum, то в будущем может появиться и более оформленная роль, условно отвечающая за внедрение AI-подходов в продукт: как в сам процесс разработки, так и во встраивание AI в пользовательские сценарии.

И ещё одну роль я намеренно оставил напоследок. Потому что именно в ней чаще всего и сходятся все противоречия HRTech-продукта: интересы бизнеса и пользователей, ограничения команды, сложность решений, давление сроков и неопределённость приоритетов. Это роль Product Owner.

Product Owner: человек, который в ответе за всё

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

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

Иногда Product Owner красиво называют mini-CIO. То есть человеком, который должен видеть всю картину, удерживать направление развития, увязывать интересы бизнеса и технологий и отвечать за результат. Но правда обычно в том, что в этой конструкции по-настоящему работает только приставка mini. Ответственность есть, а полномочия урезаны. От PO ждут взрослой позиции, но дают ему детский набор инструментов.

Но было бы слишком просто свести всё только к устройству организаций. Проблема ещё и в том, что многих Product Owner такая модель в принципе устраивает. Она им внутренне ближе. Немало людей приходят в эту роль из проектного управления, где естественной является логика координации: фиксировать статус, собирать риски, синхронизировать участников, транслировать договорённости дальше. Позиция владельца продукта устроена иначе. Она требует не только компетентности, но и внутренней готовности занимать место, где решения нужно не обслуживать, а принимать — и потом ещё за них отвечать. А это гораздо менее комфортная роль.

Здесь нередко подключается и синдром самозванца. Product Owner находится между сильными стейкхолдерами, экспертной командой, ограничениями бизнеса и постоянной неопределённостью. В такой ситуации очень легко начать воспринимать себя не как человека, имеющего право на решение, а как посредника между теми, кто якобы по-настоящему знает лучше. Особенно если у PO нет собственного практического опыта в предметной области и раньше он работал в модели заказчик-исполнитель. Он может прекрасно понимать, как нужно, может много раз предлагать разумные решения на утверждение, но если до этого он сам никогда не принимал таких решений, это становится уже не только ролевой, но и психологической проблемой.

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

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

Product Owner не должен быть самоуверенным. Но он обязан быть уверенным в своих силах и в решениях, которые принимает с учётом всей сложности контекста. Делай, что должен, — и будь что будет. Лучше сделать много хорошего и где-то ошибиться, чем не сделать ничего из-за страха ошибки.

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

Именно поэтому сильный Product Owner нужен в любой модели. В build он не даёт продукту расползтись в бесконечный набор локальных доработок. В buy — не даёт внедрению превратиться в пассивное подчинение ограничениям коробки или в хаотичную адаптацию всего под всех. В любом случае нужен человек, который не просто координирует ожидания, а удерживает целое. Потому что в HRTech выбор между build и buy важен — но ещё важнее, есть ли у продукта тот, кто действительно готов за него отвечать.

7 способов создать HRTech

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

Для себя я выделил 7 таких вариантов и оценил их по 6 критериям: зависимости от ресурсов и компетенций (HR и tech), как внутренних, так и внешних; ограничениям в кастомизации; а также ориентировочной длительности реализации.

Некоторые критерии, например зависимость от инфраструктуры, я не стал включать, поскольку считаю их менее критичными и не хотел перегружать результаты анализа. Другие, такие как стоимость, из-за сложности оценки и существенного влияния на итоговые выводы заслуживают отдельного рассмотрения.

1. Полностью собственная разработка

Максимально автономный способ создания платформы, при котором все риски сконцентрированы внутри компании: от обладания всей полнотой экспертизы до необходимости сформировать и управлять большой ИТ-командой с продуманной концепцией её оптимизации после завершения основной фазы разработки.

Критерии:

• Требования к собственной HR-экспертизе: максимальные
• Требования к собственным tech-компетенциям: максимальные
• Ограничения кастомизации: минимальные
• Зависимость от внешней HR-методологии: минимальная
• Зависимость от внешних tech-ресурсов: минимальная
• Длительность реализации: максимальная

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

2. Заказная разработка

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

Примеры: EPAM Systems, Рексофт и др.

Критерии:

• Требования к собственной HR-экспертизе: максимальные
• Требования к собственным tech-компетенциям: высокие
• Ограничения кастомизации: минимальные
• Зависимость от внешней HR-методологии: минимальная
• Зависимость от внешних tech-ресурсов: максимальная
• Длительность реализации: максимальная

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

3. Привлечение внешней компании с опытом в HRTech в РФ

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

Примеры: MOLGA Consulting, IBS, Naumen и др.

Критерии:

• Требования к собственной HR-экспертизе: средние
• Требования к собственным tech-компетенциям: высокие
• Ограничения кастомизации: низкие
• Зависимость от внешней HR-методологии: высокая
• Зависимость от внешних tech-ресурсов: максимальная
• Длительность реализации: максимальная

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

4. Open Source-решение с самостоятельной кастомизацией

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

Примеры: OrangeHRM, Sentrifugo и др.

Критерии:

• Требования к собственной HR-экспертизе: максимальные
• Требования к собственным tech-компетенциям: максимальные
• Ограничения кастомизации: низкие
• Зависимость от внешней HR-методологии: минимальная
• Зависимость от внешних tech-ресурсов: минимальная
• Длительность реализации: высокая

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

5. Разовая покупка on-premise HRTech‑решения

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

Примеры: 1С и др.

Критерии:

• Требования к собственной HR-экспертизе: высокие
• Требования к собственным tech-компетенциям: высокие
• Ограничения кастомизации: средние
• Зависимость от внешней HR-методологии: минимальная
• Зависимость от внешних tech-ресурсов: минимальная
• Длительность реализации: средняя

Пояснения: Ваша команда получает рабочий продукт и возможность углублённой кастомизации. Большинство рисков (развитие, поддержка, эксплуатация) сконцентрированы внутри. Но даёт существенное ускорение сроков, если исходное решение в целом подходило под ваши требования. По сравнению со следующим пунктом позволяет сэкономить на последующих лицензионных платежах.

6. Внедрение готового on-premise HRTech‑решения с сохранением вендорской поддержки

Коробочное решение для on-premise установки. Основные доработки ведёт вендор, поддержка и обновления — по подписке, доступ к кодам/архитектуре ограничен.

Примеры: 1С:ЗУП КОРП, Mirapolis, Галактика и др.

Критерии:

• Требования к собственной HR-экспертизе: средние
• Требования к собственным tech-компетенциям: низкие
• Ограничения кастомизации: высокие
• Зависимость от внешней HR-методологии: высокая
• Зависимость от внешних tech-ресурсов: высокая
• Длительность реализации: средняя

Пояснения: Большинство поддержки и обновлений — на стороне вендора, гибкость (с точки зрения типовой архитектуры и функционала) ограничена стандартными возможностями продукта. Однако на практике многие компании, несмотря на регулярные лицензионные платежи и официальную поддержку, вынуждены глубоко кастомизировать или даже частично переписывать коробку под свои бизнес-процессы, что может приводить к сложности обновления, росту собственных компетенций и затрат на сопровождение.

7. Переход на облачное решение (SaaS)

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

Примеры: Сбер Пульс, Mirapolis и др.

Критерии:

• Требования к собственной HR-экспертизе: низкие
• Требования к собственным tech-компетенциям: минимальные
• Ограничения кастомизации: максимальные
• Зависимость от внешней HR-методологии: максимальная
• Зависимость от внешних tech-ресурсов: максимальная
• Длительность реализации: минимальная

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

Визуально результаты сравнения можно представить:

Паутинка

Сводная таблица

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

1. Набор критериев неполный. Некоторые важные аспекты, например, стоимость, вынесены в отдельные разделы статьи или требуют дополнительного анализа (вопросы юридических рисков, культурная совместимость, владение данными и др.).
2. Вес критериев неодинаков. Значимость каждого критерия сильно зависит от конкретной компании, её целей, зрелости ИТ и HR-функций, стратегии и приоритетов трансформации. Для одних организаций критичны сроки, для других — минимизация внешних зависимостей или максимальная кастомизация.
3. Контекст. В зависимости от контекста или стратегических задач и выбранной модели развития организации даже единичный критерий (например, готовность к SaaS или требование максимального контроля) может оказаться определяющим и «перевесить» остальные.

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

Вариативность архитектурного подхода

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

Платформенный способ (Platform-based, PaaS): Создание или внедрение масштабной интеграционной платформы, на базе которой строится вся бизнес-логика и реализуются HR-процессы.

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

Best-of-Breed (модульный подход, «лоскутное одеяло»): Использование набора лучших решений для различных HR-направлений (например, отдельно — рекрутмент, адаптация, обучение, кадры и пр.) с интеграцией модулей в единую систему.

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

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

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

Фактически при смешанном подходе мы получаем как все плюсы, так и все минусы обоих подходов.

HRTech — мир, который стоит на трёх слонах

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

Функционал

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

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

Процессы

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

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

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

Опыт

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

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

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

Консистентный пользовательский опыт — это не только единый дизайн. Это единые принципы навигации, понятные роли, предсказуемые статусы, прозрачные уведомления, одинаковая логика согласований. Руководитель не должен каждый раз разбираться, в какой системе согласовать изменение, где посмотреть историю сотрудника и как понять, что именно от него требуется.

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

Данные

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

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

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

И здесь без архитектуры не обойтись. Только правильно спроектированная и реализованная архитектура позволяет выстроить фундамент, способный выдержать наших «слонов» и дать им устойчивую опору.

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

Без этого невозможно устойчиво масштабировать ни build, ни buy, ни смешанную модель.

Без правильных вопросов не бывает правильных ответов

Поэтому выбор между build и buy в HRTech я бы начинал не с вопроса «какую систему купить или разработать?», а с проектирования архитектуры платформы. Но это очень характерно для нас в целом — и не только в HRTech. Выбирая дом, мы часто любим спорить о материале стен: что лучше — кирпич или тёплая керамика. Хотя начинать нужно с других вопросов: где, для чего, какой именно дом мы хотим построить и для кого.

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

Приоритеты при создании HRTech

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

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

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

1: База, необходимая для функционирования компании

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

Включает: Core HR; Workforce Administration.

Это база для работы HR‑функции.

2: Минимально необходимое для управляемого HR

Стартовый набор для перехода от просто учёта к системному управлению персоналом: найм, постановка целей, обучение и развитие. Закрывает ключевой управленческий контур. Фактически это (в совокупности с группами 1 и 0) минимально необходимый для платформы набор решений.

Включает: ATS + CRM Candidates; Performance Management; Learning Experience Platform (LXP).

3: Расширенный функционал для развития HR

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

Включает: Assessment Hub; Offer & Contract Management; Onboarding Experience; Employee Engagement; Career & Mobility Hub.

4: Максимальный функционал и стратегическое управление

Стратегические решения — бренд работодателя, преемственность, организационное проектирование, компенсации и alumni‑сеть. На этом уровне HR-платформа становится драйвером долгосрочной бизнес‑стратегии.

Включает: Talent Marketing Platform; Talent & Succession Planning; Offboarding & Alumni Network; Org Design & Workforce Planning Platform; Compensation & Rewards Management.

0: Продукты, отвечающие за платформенность

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

Включает: Employee Profile Hub; People Analytics Platform; HR Automation Engine.

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

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

• Talent Marketing Platform — может относиться к группе 3 в компаниях с интенсивным массовым наймом.
• Offer & Contract Management — при сильном акценте на цифровом документообороте может быть отнесён к группе 1.
• Onboarding Experience — в ряде организаций адаптация считается базовой и перемещается в группу 2.

Но в целом предложенная схема отражает типовую эволюцию HR‑платформы, формируя три уровня зрелости платформы. Такой подход позволяет определить приоритеты, сформировать roadmap, спрогнозировать затраты и разнести их по времени.

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

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

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

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

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

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-платформу, а не набор решений.

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

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

Сколько стоит HRTech-платформу построить?

При сравнении способов построения HRTech-платформы я осознанно не оценивал ключевой критерий выбора для любой коммерческой организации — затраты.

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

Таким образом, по мере увеличения размера компании собственная платформа начинает давать эффект масштаба: многие функции переиспользуются, а дальнейший рост затрат для in‑house решения смещается в сторону инфраструктуры и эксплуатации. Это потенциально может повысить экономическую привлекательность такой модели развития HRTech по сравнению с приобретением решения от вендора, лицензируемого по числу сотрудников.

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

Но для того чтобы выбор подхода был более прикладным, давайте крайне грубо оценим порядок стоимости полноценной HRTech‑платформы для двух крайних способов: полностью собственная разработка и облачное решение SAP SuccessFactors. Последнее сейчас недоступно для России, но всегда было одним из мировых бенчмарков, поэтому позволит оценить верхнюю границу бюджета для готового решения.

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

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

Обращаю внимание, что дальше будет очень грубая оценка, основанная на большом количестве допущений, упрощений и упущений. Её цель — дать ориентир, а не определить точный бюджет.

Собственная разработка

Структура команды

Для крайне грубой оценки порядка стоимости полностью собственной HRTech-платформы возьмём стандартную продуктовую команду:

• 1 Product Owner
• 1 Project Manager или Scrum Master
• 1 Аналитик
• 1 UX/UI-дизайнер
• 2 Frontend-разработчика
• 2 Backend-разработчика
• 1 QA-инженер
• 1 DevOps-инженер

Получается около 10 человек. Такая команда сейчас будет стоить порядка 5 млн рублей в месяц с учётом всех накладных расходов из расчёта около 3 тыс. рублей в час за человека.

Длительность работы

Этой команде потребуется около трёх месяцев на создание MVP (Minimum Viable Product). Затем ещё полгода на EVP (Early Valuable Product), после которого ещё около года будет происходить активный рост функционала. То есть с момента зарождения до зрелости успешного продукта пройдёт около двух лет.

Перемножив одно на другое, мы получим, что для создания одного собственного продукта внутри HRTech-платформы потребуется порядка 120 млн рублей.

Количество продуктов в платформе

За основу предлагаю взять описанный ранее набор из 18 продуктов, сгруппированный по трём ступеням развития HRTech-платформы:

• Минимально необходимое для управляемого HR — 8 продуктов (включая платформенный слой)
• Расширенный функционал для развития HR — 13 продуктов
• Максимальный функционал и стратегическое управление персоналом — 18 продуктов

Оценка стоимости

Тогда, если принять среднюю стоимость создания одного продуктового контура за 120 млн рублей, то получим: 960 млн рублей, 1 560 млн рублей и 2 160 млн рублей соответственно.

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

Но для нашей задачи, я думаю, это вполне наглядная оценка стоимости разработки собственной HRTech‑платформы до полноценного рабочего состояния — это от порядка 1 млрд рублей для платформы «начального» уровня (конечно, «начального» применительно к enterprise‑уровню крупных компаний) до примерно 2 млрд рублей для полноценной платформы.

В крупных компаниях итоговая стоимость может оказаться выше базовой оценки в 1,5–3 раза — в зависимости от сложности ландшафта, глубины интеграций, уровня бюрократии и готовности компании к быстрым изменениям. Сюда же можно отнести возросшие затраты на тиражирование и инфраструктуру. Плюс на таком объёме достаточно быстро заметную роль начнут играть затраты на сопровождение уже созданного функционала, переданного в эксплуатацию.

Получается, что если у вас:

• бюджет до 1 млрд рублей — выбор в пользу полностью собственной HRTech‑платформы выглядит сомнительным;
• бюджет от 1 до 2 млрд рублей — можно пробовать, если есть уверенность в готовности компании поддержать создание этой платформы всеми необходимыми внутренними изменениями. Эти изменения должны происходить в сжатые сроки, без лишней волокиты, а в продукты должны закладываться оптимальные решения без избыточных усложнений;
• бюджет от 2 до 3 млрд рублей — позволит меньше ограничивать себя в архитектурных и продуктовых решениях, а также даст больший запас прочности для параллельной разработки и сложных интеграций, но всё ещё будет предполагать организационную и культурную зрелость;
• бюджет от 3–4 млрд рублей и выше — создаёт возможность строить HRTech‑платформу одновременно с более широкой организационной и культурной трансформацией компании, но резко повышает требования к качеству управления программой изменений, чтобы трансформация не превратилась в «производственный ад» из‑за возросшего объёма изменений и выделенных на это ресурсов.

Внедрение готового облачного решения

Для оценки стоимости облачного решения я решил взять SAP SuccessFactors. Сейчас это решение недоступно в России, но в качестве одного из глобальных бенчмарков оно позволяет оценить верхнюю планку бюджета.

Это решение лицензируется по модели PEPM (Per Employee Per Month), то есть по стоимости за одного сотрудника в месяц. Оценка общего значения PEPM для полного развёртывания набора SuccessFactors в компаниях численностью от 5 000 до 20 000 сотрудников взята из статьи:

Для полного развёртывания набора SuccessFactors при 10 000 сотрудников достижимо общее значение PEPM $28–$34 при согласованных корпоративных ставках. Для 5 000 сотрудников типично $32–$38. Для 20 000 и более сотрудников при конкурентных переговорах достижимо $22–$28.

Уровень этих оценок косвенно подтверждается и другой статьёй:

Хотя SAP не предоставляет подробной информации о ценах, некоторые основные сведения о ценах доступны на веб-сайте SAP. Облачная система SuccessFactors доступна по принципу оплаты за пользователя в месяц, при этом SAP SuccessFactors Core HR стоит 6,30 долларов США за пользователя. Более продвинутая система Core HR указана по цене 18 долларов США за пользователя в месяц.

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

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

Для своих расчётов я использовал следующие оценки:

• 5 000: $32,00-$38,00
• 10 000: $28,00-$34,00
• 20 000: $22,00-$28,00

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

• 40 000: $20,00-$28,00
• 80 000: $18,00-$28,00

Также авторы статей предлагают не забывать об индексации этих затрат. Я заложил индексацию на уровне 5%, что соответствует диапазону, обсуждаемому в источниках.

Для упрощения оценки я не усложнял модель дополнительными финансовыми аспектами, необходимыми для построения полноценной финансовой модели, например, дисконтированием. Я взял стоимость лицензирования по модели PEPM за 5 лет с учётом ежегодной индексации на 5% и добавил к ней ещё стоимость лицензий за первый год как грубую оценку затрат на внедрение. Курс я взял на момент написания статьи в 75 рублей за доллар.

Так что по деньгам?

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

• если у вас компания численностью до 10 тыс. человек и бюджет на HRTech до 1 млрд рублей, то разумнее искать готовое решение, подходящее под ваши задачи и бюджет;
• если у вас компания численностью порядка 10–20 тыс. человек и бюджет на HRTech в диапазоне 1–2 млрд рублей, то вы уже можете выбирать между собственной разработкой и лучшими решениями мирового уровня. Они будут требовать сопоставимых денег, и выбор во многом будет зависеть от функциональных требований, стратегии компании и доступности подходящего решения на локальном рынке;
• если у вас компания численностью порядка 20–40 тыс. человек и бюджет на HRTech в диапазоне 2–3 млрд рублей, то при правильной организации работ собственная разработка может оказаться дешевле самых дорогих готовых решений;
• если у вас компания численностью более 40 тыс. человек и бюджет на HRTech выше 3–4 млрд рублей, то собственная разработка, вероятно, поможет существенно сэкономить на цифровой трансформации — при условии, что компания справится со всеми связанными с этим рисками и сможет создать такую платформу за несколько лет, а не сожжёт весь бюджет в «производственном аду».

Checklist выбора готового решения для HRTech-платформы

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

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

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

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

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

В основном же вам придётся работать с функциональными требованиями. И эту работу желательно систематизировать, чтобы предпочтения функции были оцифрованы, а не находились на уровне «нравится — не нравится».

Я рекомендую действовать по следующему алгоритму.

Сформировать опросник

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

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

При этом карта должна быть достаточно подробной. Просто отправить поставщикам перечень укрупнённых продуктов или модулей будет недостаточно.

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

• L1 — верхнеуровневый процесс. Например, Performance Management.
• L2 — подпроцессы. Например, постановка целей.
• L3 — детализированные процессы или рабочие сценарии. Например, формирование шаблона целей на цикл, каскадирование корпоративных целей на подразделения, создание индивидуальных целей сотрудника и т. д.

Такой каталог понадобится не только для опросника. Он поможет определить владельцев процессов, зафиксировать функциональные границы, разделить зоны ответственности и в дальнейшем принимать решения о развитии HRTech-ландшафта.

При этом важно не заиграться и не уйти в крючкотворство. На этом этапе не нужно детально описывать AS IS / TO BE-модели всех процессов. Это потребует неоправданных трудозатрат — сначала на создание такой модели, а затем на её постоянное поддержание в актуальном состоянии.

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

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

Определить границы и приоритеты

Для начала нужно по балльной шкале оценить текущий и целевой уровень цифровизации в разрезе имеющейся процессной модели. Чтобы оценка не была чисто субъективной, нужно проработать единые и простые критерии определения баллов.

За основу предлагаю взять следующий набор критериев:

Первичные данные — где и кем создаются данные. Попадают ли они автоматически с предыдущих этапов или вводятся/загружаются оператором вручную.

Передача данных — как данные передаются на следующие этапы в смежные системы.

Обработка — что делает система, а что делает человек внутри этого шага.

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

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

Отчётность — как формируются отчёты и аналитика.

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

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

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

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

Заполнение опросника игроками рынка профильных решений

На этом этапе нужно разослать опросник уровня L1–L2 потенциальным поставщикам решений. Сейчас его заполняют сами подрядчики. Я считаю, что это позволит определить потенциальный функциональный максимум этих систем, так как, по моему опыту, подрядчик ставит «да» в любом пункте, к которому хотя бы за уши можно притянуть его систему.

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

Работа с short-list

На основании этих ответов нужно определить несколько систем-лидеров — на конкурентном рынке оптимально три. Им уже нужно направить список L1–L3 и попросить подготовить демо-пример. Затем на основе этой демонстрации самостоятельно заполнить опросник L1–L3.

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

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

Принятие решения

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

Идеальное звучание 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‑продукт настроен в оптимальном диапазоне под задачи конкретной компании.

Заключение

Если говорить коротко, вопрос build vs buy в HRTech никогда не должен сводиться только к выбору технологии. В этот момент компания выбирает не ИТ-систему, а модель собственной HR‑трансформации — с её требованиями к процессам, данным, архитектуре, бюджету, скорости изменений и внутренней зрелости. И у этого вопроса нет универсально правильного ответа.

Проблема обычно начинается там, где бизнес ожидает от tech «серебряную пулю», способную решить все накопившиеся проблемы. Эти ожидания возлагаются то на коробочные решения с набором лучших практик, то на собственную разработку. Но если компания не навела порядок в процессах и не приняла сложных управленческих решений, результат в обоих случаях будет один. Сначала компания пытается «натянуть сову на глобус», ломая архитектуру и логику выбранного решения, а затем, не сделав организационных выводов, переносит те же самые процессы уже в собственную разработку.

При этом некачественный процесс не становится лучше после автоматизации — он лишь становится цифровым. Иногда это действительно повышает операционную эффективность, но ценой значительных затрат на разработку и поддержку силами ИТ‑специалистов. А иногда становится только хуже: если раньше проблему в процессе можно было компенсировать вручную, то теперь работу блокирует автоматизированная система, в которую изначально заложили порочную схему.

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

Поэтому к вопросу build vs buy важно подходить всесторонне и без лишних иллюзий.

Соберу основные выводы

1. Не ограничивайте выбор двумя крайностями. Не стоит сводить всё только к развилке «делать самим или покупать готовое». Возможностей значительно больше. Можно найти технологического партнёра, который поможет внутренней команде создать платформу или возьмёт эту задачу на себя. Можно использовать open source‑решение или продукт вендора как основу и адаптировать его под свои процессы. Можно купить подписку на облачное решение. Наконец, можно комбинировать эти подходы в разных частях ландшафта.

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

2. Фокусируйтесь не на способе создания, а на целостности решения. Для успешной трансформации нужен не набор разрозненных инструментов, а полноценная платформа. Поэтому важнее не способ её создания, а наличие: необходимой функциональности, сквозных end-to-end‑процессов, консистентного пользовательского опыта и единого пространства данных. Именно это и делает трансформацию по-настоящему цифровой.

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

3. Будьте реалистами в оценке стоимости. У любой трансформации есть цена. И, по крайней мере сейчас, tech стоит денег. Возможно, AI и low‑code со временем радикально изменят индустрию разработки, но даже в этом случае речь, скорее всего, пойдёт прежде всего о сроках, а не об исчезновении затрат как таковых. Эти затраты просто сместятся: с разработки решений — на использование соответствующих сред и инструментов.

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

5. С самого начала формируйте реалистичные ожидания. Как бы сильна ни была вера в необходимость трансформации, одной веры на весь путь может не хватить. Поэтому с самого начала важно задать реалистичные ожидания, а затем регулярно отслеживать динамику их достижения. Иначе разрыв между ожиданиями и фактом может разрушить первые результаты, даже если трансформация в целом движется в правильном направлении.

Практический итог

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

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

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

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

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

При этом цифровая HR‑трансформация становится источником эффекта только тогда, когда компания одновременно:

• определяет целевую HR‑модель;
• умеет приоритизировать функциональность;
• выстраивает архитектуру платформы;
• готова последовательно управлять изменениями на протяжении нескольких лет.

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

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

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