Какими параметрами должна обладать промышленная HCM-система?

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

Автор: Светлана Родионова, Директор по развитию продукта VK People Hub Talent

Первое время, с уходом иностранных систем управления талантами (HCM), российский HR tech рынок находился в некотором ступоре. С одной стороны, было множество российских решений, которые, как заплатки, закрывали минорные потребности, и объединить их в сквозной цикл не представлялось возможным. С другой стороны, существовали старые отечественные HCM системы, которые в силу конкуренции или не развивались вовсе, или развивались в лучшем случае для сегмента малого-среднего бизнеса.

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

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

Итак, для начала перечислим основные параметры, которыми должна обладать система управления талантами, чтобы ее можно было охарактеризовать как промышленное решение?

Отчуждаемость от материнской компании:

· возможность легко адаптировать систему под нужды различных организаций, независимо от их размера и отрасли;

· использование независимых компонентов, без привязки к инфраструктуре разработчика;

· поддержка мультифункциональных подразделений и географически распределенных команд.

Регулярные обновления:

· постоянное обновление функционала и безопасности системы;

· актуализация системы в соответствии с изменениями законодательства;

· внедрение новых технологий и лучших практик управления талантами.

Наличие готовых инструментов интеграции:

· наличие программного интерфейса загрузки и регулярного обновления данных из сторонних систем (ERP, CRM и других внутренних систем);

· возможность загрузки данных через файлы (Excel, CSV) в форматах XML или Json;

· возможность настройки регулярности обновления данных и логирования результатов интеграционных процессов;

· использование стандартных API и коннекторов для бесшовной интеграции.

Наличие сервисов стандартной и расширенной технической поддержки:

· регулярное устранение ошибок в рамках выпуска обновлений системы;

· наличие процессов подачи и приема заявок от клиентов или партнеров по возникающим ошибкам и иным вопросам, касающимся работы и эксплуатации системы;

· наличие выделенной команды для обработки заявок и проведения консультаций;

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

Наличие партнерской сети (интеграторов):

· расширенная партнерская сеть, обеспечивающая внедрение и поддержку решения;

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

Функциональность:

· широкий спектр модулей, охватывающих все аспекты управления талантами: от рекрутинга и адаптации до развития и удержания сотрудников;

· возможности использования инструментов аналитики для принятия обоснованных решений;

· наличие понятной дорожной карты развития продукта.

Гибкость:

· административная панель администратора системы с расширенным инструментарием гибкой настройки и адаптации модулей под процессы компании.

Производительность и масштабируемость:

· отсутствие отказоустойчивости системы при увеличении нагрузки (рост количества пользователей);

· наличие подходов по масштабированию системы при увеличении нагрузки на систему;

· соответствие стандартам разработки решения, наличие платформы разработки, комплементарное современным ИТ-технологиям.

Соответствие отечественным стандартам, нормативной и правовой базам:

· регистрация решения в Росреестре отечественного ПО;

· соответствие требованиям в части ИБ и защиты персональных данных;

· использования сторонних компонентов, входящих в список отечественного ПО;

· совместимость с альтернативным ПО, используемым в инфраструктуре заказчика.

Наличие у разработчика собственных ИТ-продуктов для смежных областей деятельности предприятия:

· наличие смежных продуктов, позволяющих расширить функциональность системы (экосистема);

· наличие понятных, сквозных механизмов интеграции со смежными системами.

Далее разбираем все пункты подробно, даем комментарии и пояснения.

Отчуждаемость от материнской компании

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

С какими подводными камнями мы можем столкнуться в порядке критичности?

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

Скорее всего, никто не думал о том, что будет дальше подписания договора-продажи. Кто будет внедрять? Поддерживать? Как будет происходить обновление?

Решение заключает в себе внутреннюю методологию ведения процессов; многое, что “зашито”, не настраивается, и она не всегда соответствует лучшим практикам.

Антон Рябов, CTO продукта VK PH Talent: «Если говорить про наше HCM-решение, то мы изначально разрабатывали его как рыночный продукт, при этом пройдя путь «болезненного роста» от заказной разработки до формирования коробочного решения. Данный подход позволил корректно спроектировать систему и заложить команды на его поддержку и развитие».

Итак, какие вопросы необходимо задать на этапе выбора решения?

Система может разворачиваться и работать в целевой инфраструктуре?

Есть ли проприетарное ПО, требующее приобретения дополнительных лицензий при поставке системы?

Отсутствуют ли компоненты, требующие подключения к внешней сети интернет для загрузки и обновления зависимостей?

Какие возможности развертывания с использованием контейнеризации и работы системы в отказоустойчивом кластере (Docker + Kubernetes)?

Есть ли возможность интеграции с каталогом пользователей домена (ов) компании и настройки SSO? Возможность бесшовной авторизации?

Регулярные обновления

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

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

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

Антон Рябов, CTO продукта VK PH Talent: «В нашем случае система внедряется обученной командой партнеров-интеграторов, основной код ядра является закрытым и поставляется в скомпилированном виде. При этом в систему внедряются точки расширения, позволяющие клиенту изменять или расширять типовую функциональность. В зависимости от уровня (фронт/бэк) или конкретного микросервера регламентируются различные подходы к расширению функциональности. И на каждый из них написана документация для разработчиков. При таком подходе мы можем дорабатывать решение, при этом не теряя возможности устанавливать регулярные обновления».

Вопросы:

Частота обновлений системы? Что входит в обновление?

При выходе нового модуля необходимо ли его оплачивать отдельно?

Какими критериями должна обладать система на стороне заказчика, чтобы обновление прошло наиболее безболезненно?

Наличие готовых инструментов интеграции

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

Как правило, отсутствием готовых решений грешат системы от компаний (см. пункт про отчуждаемость) или небольшие стартапы.

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

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

Вопросы:

Наличие унифицированного программного интерфейса для загрузки данных.

Возможность передавать данные через файлы или форматы типа XML или Json.

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

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

Наличие сервисов стандартной и расширенной технической поддержки

При работе с иностранными вендорами практически никто об этом даже не задумывался. Наличие поддержки считалось нормальным, и единственное, о чем мы спорили, это формат поддержки 24/7 или 5/5. Но ситуация на рынке изменилась, и тут мы снова возвращаемся к решениям, которые изначально не создавались как рыночные, или решениям-однодневкам.

Наталья Плешивцева, руководитель группы продаж продукта VK PH Talent: «Если мы говорим о стандартной поддержке, то здесь должна быть выделена команда, которая будет составлять очереди обновлений в соответствии с релизной политикой (дорожной картой развития продукта), готовить и тестировать их и своевременно информировать об этом заказчика. В случае возникновения ошибок – отрабатывать обращения в соответствии с заявленным уровнем сервиса и в заранее созданном пространстве. Должны быть доступны обучающие материалы. Конечно, можно стартовать и без выделенной команды, но тогда нужно четко понимать, что вы покупаете решение и дальше вся ответственность за его поддержку на вашей стороне.

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

Вопросы, которые стоит задать этапе выбора системы:

Кто и как будет осуществлять стандартную и расширенную поддержку?

Есть ли выделенная команда, к которой можно обратиться за консультациями по работе системы?

Какие специалисты будут осуществлять сопровождение системы после ее установки?

Наличие партнерской сети (интегратора)

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

Юрий Кольченко, руководитель отдела по развитию продуктовой экосистемы продукта VK PH Talent: «В случае работы с малым и средним бизнесом вендор может себе позволить сделать простое решение, которое самостоятельно будут внедрять сотни интеграторов. При этом позволительно отсутствие контроля качества, низкий уровень знаний партнеров, отсутствие поддержки и прочее. Мы же создали комплексную систему для крупного бизнеса и у нас было изначальное понимание необходимости сильной партнерской сети, где мы с клиентом можем довериться партнеру. Поэтому на первом этапе у нас порядка 10 партнеров, и каждый из них с именем, историей и гарантией качества».

Вопросы, которые стоит задать этапе выбора системы:

Есть ли у вас партнерская сеть? Какие компании в нее входят?

Кто будет заниматься внедрением и дальнейшей поддержкой системы?

Какова система тарификации? Есть ли риск неучтенных в КП расходов?

Как распределяется ответственность между вами и интеграторами?

Что будет в случае нарушения сроков внедрения системы?

Функциональность

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

Ксения Досанова, руководитель группы бизнес-архитектуры продукта VK PH Talent: «В нашем решение мы абстрагировались от понятия «модули», как принято на рынке и у западных коллег, а перешли в парадигму бизнес-сценариев или бизнес-решений, которые в нашем понимании отражают комплексный бизнес-процесс от начала до конца. Вот, например, для того, чтобы решить задачу по подбору и назначению сотрудника на какую-то ключевую позицию, необходимо сразу несколько элементов из разных модулей: создать конкретный профиль и привязать туда конкретные компетенции из каталога; определить перечень ключевых для бизнеса позиций и отобрать на эти позиции талантливых сотрудников (используя инструменты оценки); сформировать сотрудникам ИПР, основываясь на западающие компетенции, пройти обучающие мероприятия; снова оценить и назначить на позицию, не забыв при этом про адаптацию; и вновь по кругу.

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

Вопросы, которые стоит задать этапе выбора системы:

Какие модули входят в решение? Какие потребности они закрывают?

Какая дорожная карта решения?

Можно ли влиять на приоритетность выхода поставки?

Гибкость

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

Вопросы, которые стоит задать этапе выбора системы:

Каким образом происходит изменение процессов в системе: кодинг или настройка?

У кого есть права на настройку системы? Нужно и для этого специальное обучение, сертификация?

Какие возможности конфигурации бизнес-процессов и управления НСИ?

Уровень отказоустойчивости

Антон Рябов, CTO продукта VK PH Talent: «Тут разговоры излишни, система должна быть стабильна при максимально доступном количестве пользователей. В ином случае, при пиковой нагрузке (постановка и оценка целей) приходится отдельно контролировать численность сотрудников, работающих с системой искусственно созданными графиками последовательности. При этом важно учитывать и потенциал системы при ее тиражировании и масштабировании».

Выявить уровень отказоустойчивости помогут следующие вопросы:

Проводилось ли нагрузочное тестирование системы? Какие параметры получены? Какое максимальное число пользователей одновременно могут работать с системой?

Есть ли план с уровнями нагрузки (количество пользователей) и соответствующими техническим требованиям в части серверных мощностей.

Есть ли описанные подходы по масштабированию системы при увеличении нагрузки.

Какое среднее время восстановления системы?

Соответствие отечественным стандартам, нормативной и правовой базам

Тут за нас все решило государство. И если к частным компаниям вопросов поменьше, то госкорпорации обязаны до конца 2025 года перейти на отечественные решения. А под отечественными решениями мы понимаем не те, что были написаны на территории РФ, а те, которые содержат разрешенные к использованию компоненты.

Ну а вопрос тут простой: зарегистрировано ли ваше решение в Росреестре отечественного ПО?

Наличие у разработчика собственных ИТ-продуктов для смежных областей деятельности предприятия

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

Ксения Досанова, руководитель группы бизнес-архитектуры: «Мы понимаем, что целостность покрытия в рамках общего процесса “управление персоналом” более интересна рынку и имеем в портфеле комплекс решений в этой области. Своими решениями мы покрываем запросы и “синих” и “белых” воротничков, и руководства, и владельцев бизнесов. Там, где мы не планируем собственное покрытие по бизнес-процессам, подбираем лучших для интеграции. Мы как вендор пошли в коллаборацию с сильнейшими и создаем комплексные HR tech экосистемы из своих продуктов и продуктов коллег, продумывая при этом стыковки и на методологическом, и на технологическом уровнях, делая процессы для конечных пользователей целостными и продуктивными».

Вопросы, которые стоит задать этапе выбора системы:

Какие еще системы есть в портфеле вендора?

Есть ли связи между системами? Как они взаимодействуют между собой?

Какие условия приобретения комплексного решения? Это одна лицензия или несколько?

Как осуществляется поддержка комплексного решения?

Надеюсь, наш материал поможет вам в выборе оптимального решения, которое закроет основные бизнес-потребности. Если у вас остались вопросы, или есть темы, которые тревожат, и вы хотите получить на них ответ, пишите нам web@goodt.me, и мы с радостью попробуем вам

11
Начать дискуссию