Автоматизация HR сегодня смещается от «набора функций» к управлению сквозными цифровыми процессами и опытом сотрудника, и именно здесь ломается логика типичных запросов предложений (RFP/RFI) и ТЗ на HR-системы.

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

1. Почему фокус на функциях в запросах предложений/ТЗ ведет к удорожанию и срывам

Типичный запрос компании к вендору выглядит как длинный чек-лист: «система должна уметь…», где перечислены десятки или сотни функций без приоритизации и связи с реальными процессами и метриками.

Ключевые проблемы такого подхода:

• Раздувание объема проекта. В запрос предложений попадает максимум возможных хотелок от разных стейкхолдеров; вендор, чтобы остаться в шорт-листе, закладывает поддержку почти всего списка. Это автоматически увеличивает лицензионный периметр, объем внедрения и цену.
• Отсутствие фокуса на критических процессах. Вместо того чтобы быстро «закрыть боль» (например, онбординг, КЭДО или управление целями), проект превращается в многолетнюю попытку реализовать все функции сразу. Пока идет проект, HR продолжает работать в Excel, почте и мессенджерах.
• Позднее выявление проблем в процессах. Сложные функции (сложные схемы согласования, необычные модели грейдов, экзотические KPI) вскрывают провалы в регламентах уже на этапе реализации: оказывается, что даже внутри компании нет единого понимания, «как должно работать». Приходится перепроектировать процессы, менять требования и переделывать уже реализованные части.
• Рост TCO и выгорание команды. Из‑за постоянных изменений требований «по ходу дела» растут сроки, стоимость доработок и нагрузка на обе стороны, а эффект от автоматизации откладывается на неопределенное будущее.

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

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

2. Подход 1: сначала процессы, потом функции

Первый продуктивный подход — перестроить логику проекта: от описания функций к описанию целевых процессов и метрик.

Суть:

1. Зафиксировать ключевые бизнес‑цели HR‑проекта: уменьшение времени закрытия вакансий, сокращение срока онбординга, снижение ручного труда в КЭДО, рост вовлеченности, улучшение управляемости данных по персоналу и т.п.
2. Описать ключевые сквозные процессы:
   • найм (от заявки до выхода на работу);
   • адаптация (онбординг с чек‑листами и задачами руководителей);
   • управление целями и оценкой (OKR/KPI, review‑циклы);
   • развитие и обучение (L&D‑контуры, витрина курсов, внутренние карьерные треки);
   • кадровый документооборот и сервисные запросы сотрудников.
3. На уровне процессов сформулировать требования: какие шаги должны быть автоматизированы, какие участники вовлечены, какие данные используются, какая аналитика нужна.
4. Уже после этого производить маппинг в функции платформы: какие конкретные модули, виды заявок, типы задач, роли, интеграции и отчеты необходимы для поддержки процесса.

Преимущества такого подхода для заказчика и вендора:

• Сокращение объема «лишнего» функционала: остаются только функции, которые поддерживают приоритетные процессы и влияют на KPI.
• Более точная оценка сроков и стоимости: вендор видит понятные сценарии, а не абстрактные хотелки.
• Меньше переделок: если процесс описан и согласован заранее, риск «открыть ящик Пандоры» на этапе внедрения значительно ниже.
• Быстрый выход на пилот: можно сразу выделить 1–2 процесса для MVP и планировать поэтапный запуск.

Российские платформы, ориентированные на процессный подход (например, Incomand, Neon HRM, решения ТопФактор и др.), как правило, предлагают встроенные BPMN/low‑code-конструкторы, позволяющие сначала формализовать HR‑процессы, а затем быстро собрать вокруг них формы, маршруты согласования и интерфейсы без глубокого программирования.

3. Подход 2: сначала коробка, потом улучшения

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

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

Механика:

1. Выбор коробочной платформы, в которой уже есть типовые сценарии: кадровый портал, заявки сотрудников, база знаний, типовые процессы найма, адаптации, оценки, обучения, КЭДО.
2. Быстрый запуск базовой версии: подключение всех сотрудников, минимальная кастомизация (брендинг, структура, базовые роли), включение ключевых модулей.
3. Сбор фактической обратной связи и данных использования: какие разделы востребованы, где затыки, какие процессы требуют доработки.
4. Поэтапная кастомизация и развитие: донастройка форм, маршрутов, карточек, добавление интеграций на основе реальных сценариев, а не гипотетических RFP.

Плюсы такого подхода:

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

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

4. Как вендору и заказчику «пересобрать» подход к запросу предложений/ТЗ

Чтобы уйти от удорожания и затягивания проектов, обеим сторонам полезно изменить формат исходных документов и диалога.

Рекомендации заказчику:

• Вместо огромного функционального чек‑листа сформировать 5–7 ключевых процессов и целей, описав текущую «как есть» и желаемую «как должно быть» картину.
• Разделить требования на «обязательные» (must‑have) и «желательные» (nice‑to‑have) с привязкой к бизнес‑эффекту и срокам.
• Заложить в RFP возможность поэтапного запуска: сначала MVP на коробочном решении, затем расширение и кастомизация.

Рекомендации вендору:

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

Инкоманд удобен как пример для оптимальной реализации обоих рассмотренных подходов именно потому, что это прежде всего конструктор, а не фиксированный набор HR‑модулей. Платформа дает единый каркас (портал, процессный движок, объектную модель и интеграционный слой), к которому с помощью конструкторов интерфейсов, приложений и процессов «пристегиваются» конкретные сценарии жизненного цикла сотрудника: от подбора и онбординга до развития, внутренних переходов и ухода. В требованиях можно указать не «нам нужен модуль X», а последовательности шагов: как кандидат попадает в экосистему, какие задачи и уведомления получает новичок в первые 90 дней, как выглядит путь сотрудника при смене роли, — зная, что все это будет собрано из готовых блоков конструктора, а не за счет штучных доработок под каждый процесс. При сравнении с другими российскими решениями (Битрикс24 HRM, Пряники, HRBOX и др.) это помогает сформировать более процессно‑ориентированную карту, где каждый вендор занимает понятное место: кто сильнее в коммуникациях, кто — в глубокой HRM‑аналитике, кто — в портальной логике и low‑code.

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