7 способов создать HRTech

Материал входит в серию статей о build vs buy в HRTech.

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

Для себя я выделил 7 таких вариантов и оценил их по 6 критериям: зависимости от ресурсов и компетенций (HR и tech), как внутренних, так и внешних; ограничениям в кастомизации; а также ориентировочной длительности реализации.

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

Максимально автономный способ создания платформы, при котором все риски сконцентрированы внутри компании: от обладания всей полнотой экспертизы до необходимости сформировать и управлять большой ИТ-командой с продуманной концепцией её оптимизации после завершения основной фазы разработки.

Критерии:

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

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

Примеры: EPAM Systems, Рексофт и др.

Критерии:

Пояснения: Вся кастомизация доступна, если есть чёткое ТЗ и возможности управлять подрядчиками. Технические компетенции для сбора, координации, контроля и интеграции критичны.

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

Примеры: MOLGA Consulting, IBS, Naumen и др.

Критерии:

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

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

Примеры: OrangeHRM, Sentrifugo и др.

Критерии:

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

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

Примеры: 1С и др.

Критерии:

Пояснения: Ваша команда получает рабочий продукт и возможность углублённой кастомизации. Большинство рисков (развитие, поддержка, эксплуатация) сконцентрированы внутри. Но даёт существенное ускорение сроков, если исходное решение в целом подходило под ваши требования. По сравнению со следующим пунктом позволяет сэкономить на последующих лицензионных платежах.

Коробочное решение для on-premise установки. Основные доработки ведёт вендор, поддержка и обновления — по подписке, доступ к кодам/архитектуре ограничен.

Примеры: 1С:ЗУП КОРП, Mirapolis, Галактика и др.

Критерии:

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

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

Примеры: Сбер Пульс, Mirapolis и др.

Критерии:

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

Визуально это можно представить следующим образом:

В основе идентичные данные, с разными визуальными представлениями.

Может возникнуть соблазн просто просуммировать значения по всем критериям и выбрать тот способ построения HR-платформы, у которого сумма минимальна. Этого делать не следует по нескольким причинам:

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

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

Платформенный способ (Platform-based, PaaS): Создание или внедрение масштабной интеграционной платформы, на базе которой строится вся бизнес-логика и реализуются HR-процессы.

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

Best-of-Breed (модульный подход, «лоскутное одеяло»): Использование набора лучших решений для различных HR-направлений (например, отдельно — рекрутмент, адаптация, обучение, кадры и пр.) с интеграцией модулей в единую систему.

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

Смешанный (гибридный) подход: Комбинация платформенного и модульного подходов. В качестве базиса используется платформа (разработанная самостоятельно или приобретённая), а отдельные компоненты для критичных или уникальных функций докупаются или дорабатываются отдельно.

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

Фактически при смешанном подходе мы получаем как все плюсы, так и все минусы обоих подходов.