Как собрать и протестировать требования к HRM-системе

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

Как правильно собирать и тестировать требования к HRM-системе, на какие вопросы искать ответы до выбора платформы и как синхронизировать ожидания всех участников, чтобы автоматизация стала драйвером роста бизнеса, а не очередной «строкой в бюджете» рассказала Валерия Балтабаева, руководитель проектов HR-цифровизации K-Team HRM.

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

Самый частый сценарий провала примерно такой – участники проекта с энтузиазмом обсуждают функции, кнопки и модули, но никто не может внятно ответить на вопрос «зачем мы это делаем». Вместо того чтобы отталкиваться от бизнес-задач (сократить время адаптации, снизить текучесть), команда начинает с выбора HRM-платформы и обсуждения «как это будет выглядеть». В результате требования превращаются в бесконечный список «хотелок», не связанных со стратегией компании.

Как распознать? Вам сложно сформулировать измеримые KPI для проекта. Руководители разных департаментов просят разное и не могут договориться. На вопрос «какую проблему мы решаем» вы слышите размытые формулировки вроде «нужно улучшить коммуникации».

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

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

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

Что делать? Включите в процесс сбора требований самих пользователей. Используйте глубинные интервью, опросы и метод персон. Узнайте, какие процессы отнимают у них больше всего времени и сил. Не спрашивайте «нужна ли вам база знаний?». Спросите «где вы обычно ищете информацию, когда сталкиваетесь с нестандартной задачей?». Опирайтесь на реальные боли, а не на домыслы.

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

Как распознать? Техническое задание содержит десятки страниц с детальным описанием всех возможных функций – от оценки 360 до геймификации. Сроки реализации измеряются годом и больше. Каждый новый участник проекта добавляет новые пункты в список требований, и процесс согласования длится месяцами.

Что делать? Выделите 2-3 ключевые задачи, которые принесут быстрый и заметный результат, и запустите MVP – минимально жизнеспособную версию продукта. Получите обратную связь от пользователей, доработайте систему и только потом добавляйте новые модули.

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

Начните с аудита. Проведите ревизию текущих HR-процессов. Зафиксируйте, как сейчас выполняются ключевые задачи: адаптация, согласование отпусков, кадровый учет. Где возникают задержки? Где чаще всего случаются ошибки? Какие процессы отнимают у HR-команды больше всего времени? Важно не просто «посмотреть на процессы», а замерить их – в часах, днях, количестве ошибок.

Также оцените зрелость процессов. Если у вас нет единых регламентов, а кадровые данные хранятся в разрозненных Excel-таблицах, не пытайтесь автоматизировать «всё и сразу». Сначала наведите порядок в бизнес-процессах, а затем автоматизируйте их.

Проект по внедрению HRM – это не задача для одного человека или ИТ-команды. Требования должны формироваться совместно с теми, кто будет использовать ее и принимать решения о развитии, а именно:

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

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

Чтобы требования не были списком функций, постройте карту пути сотрудника (Employee Journey Map), которая показывает, что видит, чувствует и с чем сталкивается человек на каждом этапе взаимодействия с компанией – от найма до увольнения. Для этого можно использовать:

• Метод персон. Опишите типичных пользователей системы: новичок, линейный сотрудник, руководитель, HR-специалист. У каждой персоны – свои задачи, боли и ожидания.
• Глубинные интервью. Поговорите с сотрудниками, чтобы понять, как они сегодня решают свои задачи и с какими трудностями сталкиваются.
• Опросы. Соберите количественные данные для подтверждения гипотез.

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

«Улучшить коммуникации» или «повысить вовлеченность» – звучит хорошо, но эти цели невозможно измерить. А значит, в конце проекта вы не сможете ответить на вопрос, получилось ли у вас. Переведите каждую задачу в измеримый показатель, например:

• «Улучшить адаптацию» – «сократить время выхода новичка на плановые показатели с 6 до 3 месяцев»
• «Повысить вовлеченность» – «увеличить долю сотрудников, прошедших опрос вовлеченности, с 65% до 90%»

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

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

Выделите 2-3 функции, которые принесут быстрый и заметный результат. Это и есть ваш MVP – минимально жизнеспособный продукт. Как его выбрать?

• Оцените каждое требование по шкале важности – насколько оно влияет на бизнес-результаты.
• Спрогнозируйте сложность реализации — сколько времени и ресурсов потребуется.
• Выберите то, что дает максимум пользы при минимуме затрат.

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

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

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

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

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

Во-вторых, вы не тратите время и ресурсы на написание документа, который все равно будет переработан профессиональными аналитиками. В-третьих, вы получаете ТЗ, которое действительно отражает лучшие практики и распространенные риски.

Что должно быть в вашем реестре требований:

• Описание ролей и прав доступа – кто может создавать, редактировать, просматривать, согласовывать разделы и документы.
• Требования к интеграциям и безопасности – с какими системами (1С, Active Directory и так далее) должна обмениваться данными система.
• Критерии приемки – как вы будете проверять, что задача выполнена.

В K-Team мы помогаем клиентам на старте проекта: собираем требования, приоритезируем их, оформляем в реестр и готовим качественное техническое задание, которое становится основой для успешного внедрения. Такой подход экономит время, снижает риски и гарантирует, что ТЗ будет работать на проект, а не против него.

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

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

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

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

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

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

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

Когда речь заходит о выборе подхода к автоматизации HR, у бизнеса обычно два варианта.

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

Второй – готовое решение. В таких платформах уже заложены лучшие практики сотен внедрений. Она содержит 80–90% необходимой функциональности «из коробки». Плюсы – быстрый старт (1-3 месяца), предсказуемый бюджет, опыт других компаний. Минусы тоже есть: какие-то процессы, возможно, придется адаптировать под логику платформы, а не наоборот. Но здесь важно понимать – вы всегда можете либо адаптировать процессы на старте, либо доработать коробку под свои процессы позже, уже после запуска MVP. В любом случае это выйдет значительно дешевле и быстрее, чем разработка с нуля. Именно поэтому стоит обратить внимание на платформы с открытым исходным кодом, например, K-Team – они дают свободу действий без привязки к вендору.

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

• Какие требования для вас критичны, и если в системе их нет – это минус.
• От каких требований вы готовы отказаться.
• Где компромисс оправдан, а где – нет.

Когда HRD приходит на защиту бюджета с реестром требований, четкими KPI и пониманием, что закрывается готовым решением, а что требует доработки, он говорит с бизнесом на одном языке. Тогда решение о выделении бюджета становится очевидным.

За плечами команды K-Team более 100 успешных проектов по внедрению HRM-системы в компаниях из самых разных отраслей: от финансового сектора и ритейла до производства и логистики. Мы знаем, какие вопросы задать на старте, чтобы не упустить критичные требования, как синхронизировать ожидания всех сторон и какие подводные камни ждут на каждом этапе.

Наша экспертиза подтверждена реальными кейсами – вы можете познакомиться с ними в разделе выполненных проектов.

Сбор требований – это только первый шаг. Дальше – внедрение, развитие и постоянное улучшение системы вместе с вами. Мы не просто поставляем платформу, а становимся партнером, который помогает превратить HR-процессы в драйвер роста бизнеса. Давайте делать крутые проекты вместе!