Build vs buy в HRTech: компания выбирает не систему, а модель трансформации

Этот текст — вводный материал к серии статей о build vs buy в HRTech. Вслед за ним выйдут большая аналитическая записка и статьи с более глубоким разбором отдельных аспектов этого выбора.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На примере отдельных HR‑продуктов эта логика особенно наглядна:

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

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

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

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

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