Материал входит в серию статей о build vs buy в 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 происходит то же самое. Прежде чем выбирать между готовым продуктом, собственной разработкой или смешанной моделью, нужно понять, какую платформу мы строим, на каком фундаменте она будет стоять и какие задачи должна выдерживать в какой перспективе.