Материал входит в серию статей о build vs buy в 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.
Формат оценки — «да / нет», баллы или проценты — вторичен по сравнению с корректно определёнными критериями. Гораздо сильнее на итоговый результат влияет система весов, поскольку большее количество поддерживаемых функций не всегда означает лучшее соответствие задачам бизнеса.
При этом вес часто коррелирует с оценкой приоритета соответствующего процесса, но не всегда тождественно равен ему при выборе решения. Вес должен ещё как минимум учитывать сложность автоматизации: иногда проще самостоятельно автоматизировать процесс, чем найти готовое решение, сочетающее в себе все нужные функции.
Принятие решения
Ну а дальше начинается самое увлекательное: шантаж, торг, уговоры или, если повезёт, защита позиций с последующим взвешенным решением. Всё зависит от корпоративных традиций, но это всегда очень индивидуальный процесс. Главное, чтобы на этом шаге не была обесценена вся предыдущая работа, а выбор не оказался выбором без выбора.
Подписывайтесь, комментируйте — продолжение обязательно будет