Відмовилися від готової HRM-системи та створили власну: досвід компанії з DevOps-експертизою

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Привіт, спільното! Мене звати Павло Завада, в IT працюю вже понад 15 років — у сфері системного адміністрування та DevOps. Я CEO NETFORCE Group — екосистеми проєктів, побудованих навколо цієї експертизи. Ми закриваємо повний цикл потреб на ринку: надаємо сервісні послуги для бізнесу, навчаємо фахівців, забезпечуємо спеціалізований рекрутинг для клієнтів та пошук роботи для кандидатів.

Усі 11 років існування NETFORCE Group наш фокус та ресурси були спрямовані саме на ці спеціалізовані проєкти. Але нещодавно до звичних для нас напрямів додався новий: HRM-система NETFORCE Work.

Коли на ринку існує стільки готових продуктів, рішення розробляти власну HRM-систему може здаватись нелогічним. Тож тут я розповім, чому ми відмовилися від популярної платформи, як застосували DevOps-підхід до розробки HRM-системи та поділюся висновками, які зробив у процесі.

Як у нашій компанії змінювався підхід до HR-процесів

Як і багато стартапів та невеликих компаній, на початку ми використовували найдоступніші інструменти й не думали про платні рішення.

Коли в команді було до 20 співробітників, ми легко справлялися з HR-процесами. Інформація не губилась, баланс відпусток можна було вести у звичайній таблиці. До того ж це були доковідні часи, коли вся команда працювала в одному офісі. HR-процеси багато в чому трималися на постійній комунікації, і цього було цілком достатньо.

Але коли команда зросла до 25+ співробітників, процеси всередині компанії перестали працювати так само ефективно. Найперше це стало помітно на базових процесах.

Облік відпусток та лікарняних став забирати багато часу ручної роботи. Ми потребували рішення, яке б автоматизувало ці завдання і зменшило ризик помилок. Адже завжди можна забути оновити дані в таблиці, а потім доводиться перераховувати і звіряти залишки.

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

Зі свого боку я бачив, що забагато інформації зав’язано особисто на мені. Команда потребувала місця, де кожен зміг би самостійно знайти необхідну інформацію і закрити базове питання.

Тоді ми зрозуміли, що нам потрібна HRM-система. Обрали одне з популярних на українському ринку рішення і перенесли процеси туди.

Чому вирішили створювати власну HRM-систему

Щоб відповісти на це питання, поділюсь нашим досвідом користування готовим продуктом.

Насправді, після впровадження ми відчули позитивні зміни. Багато процесів, які раніше трималися на таблицях, усних домовленостях і постійній комунікації, вдалося об’єднати в одній системі. Співробітникам стало простіше знаходити потрібну інформацію чи подавати запити, а HR-процеси були під контролем.

Водночас команда продовжувала зростати, а ми — помічати недоліки й обмеження обраної платформи. Доводилося шукати обхідні шляхи або перебудовувати процеси під можливості системи. І що більше розвивалась наша компанія, то помітнішим ставав цей компроміс. Це не означає, що продукт був поганим. Просто він створювався як універсальне рішення для багатьох компаній.

Платформа продовжувала розвиватись, з’являвся новий функціонал. Але він не відповідав нашим потребам. Виходило, що ми платили за весь пакет, але використовували лише його частину. А коли потребували специфічний сценарій для нашої компанії, не могли його отримати.

Готова HRM-система була одночасно надлишковою і недостатньо гнучкою. З часом таких обмежень стало достатньо, щоб поставити собі питання: продовжувати підлаштовувати свої процеси під продукт чи створити систему під свої потреби?

Відповідь була однозначна. Ми мали в штаті команду розробників та достатньо експертизи, щоб створити власне рішення.

Як створювали та розвивали платформу

Від рішення створити платформу до запуску першої версії минуло лише 2 місяці. Зауважу, що йдеться про базовий функціонал, але вже на цьому етапі команда могла повноцінно використовувати систему у роботі.

У першу версію увійшли:

• База співробітників та їхні профілі — єдиний простір із контактами й необхідною інформацією про кожного.
• Організаційна структура компанії — схема, де зображено, хто в якій команді працює та дає розуміння, до кого звертатися з конкретними питаннями.
• Оформлення відпусток та інших відсутностей — можливість подати запит у кілька кліків, відстежувати його статус та швидко отримати затвердження.
• Загальний календар — щоб бачити, хто сьогодні не на зв’язку, та не забувати про важливі дати чи дні народження.
• Гнучке управління доступами — безпечна роздача прав перегляду даних.

Оскільки ми самі щодня користувалися системою, то одразу бачили, чого не вистачає, а що можна спростити. Ми помічали потребу, визначали пріоритет і ставили завдання розробникам. Це одна з головних переваг розробки власного продукту.

Крім того, ми щодня займаємося DevOps на клієнтських проєктах, тому й до власної HRM-системи висували високі вимоги. Від самого початку ми закладали архітектуру, яка гарантує стабільну роботу під навантаженням та миттєве завантаження сторінок. Окремим пріоритетом була безпека — надійний захист конфіденційних даних співробітників та компанії ми передбачили ще на рівні розробки.

Що стосується технічної частини, бекенд платформи побудований на Laravel 13 із використанням бази даних MariaDB. Для кешування та управління чергами повідомлень ми задіяли Redis і RabbitMQ, а вебсервером виступає Nginx. Усе це контейнеризовано через Docker. Щодо фронтенду, ми обрали Vue.js у зв’язці з TypeScript, а для швидкої збірки використовуємо Vite. Такий стек дає змогу підтримувати високу швидкість роботи системи, масштабувати її та безпечно випускати оновлення.

Як власна HRM-система показала себе на практиці

Зараз минуло 8 місяців від впровадження платформи для команди, і за цей час вона суттєво змінилася порівняно з першою версією. Окрім покращення наявних інструментів, ми розширили функціонал до того, який нам справді потрібен.

Серед іншого, можу виокремити таке:

• Стрічка новин, щоб усі команди були поінформовані про життя та оновлення в компанії. Окремо — оголошення для важливих та термінових повідомлень.
• Імейл-розсилки, які можна створювати одразу в системі та за готовими шаблонами, без використання додаткових платформ.
• Тижневі звіти для швидкої синхронізації, а також планування зустрічей 1-on-1 одразу в системі, коли у фахівця виникає такий запит.

Про те, як HRM-система скорочує час на рутинні завдання і скільки годин вивільняє, повторюватись не буду — про це вже багато написано. Натомість хочу поділитись кейсом.

Показовим для мене став період, коли наша компанія на деякий час залишилася без HR-менеджера. Основні процеси при цьому продовжували працювати: співробітники подавали запити, знаходили потрібну інформацію, а погодження відбувалось за звичним сценарієм. І я зовсім не про те, що маючи HRM-систему, компанії більше не потрібен HR-фахівець. Навпаки, це доводить: коли система забирає рутину на себе, HR-менеджер може сфокусуватися на важливому — адаптації та розвитку співробітників, покращенні внутрішніх процесів.

Куди рухається HRM-платформа далі

Наразі ми продовжуємо розвивати платформу. У серпні ми публічно релізнули NETFORCE Work, тому це вже не лише внутрішній інструмент нашої компанії — HRM-системою можуть користуватися й інші команди.

Наступний крок у розвитку HRM-системи — створення модуля для рекрутингу.

Зараз для таких завдань ми використовуємо готовий продукт. Це ще один інструмент, між яким доводиться перемикатись. Також це додаткова ручна робота: коли кандидат приймає офер і стає співробітником, частину його даних треба переносити в HRM-систему. До того ж в окремій системі для рекрутингу залишається вся історія комунікації, фідбеки з технічних співбесід та інший контекст.

Ми хочемо, щоб шлях від першого контакту з кандидатом до його онбордингу та подальшої роботи в компанії відбувався в одному просторі.

Чи виправдана власна розробка

Якщо рахувати суто математично, розробка власної HRM-системи виключно для внутрішніх потреб команди на 30-50 співробітників — це дорого. Якби ми продовжували використовувати готовий продукт, ми б зекономили. Зарплати розробників та всієї команди, залученої до створення платформи, в рази перевищують вартість підписки.

Але для нас це мало сенс. У процесі розробки та щоденного користування ми побачили, що проблеми, які ми вирішували для себе, виникають у багатьох компаній. Саме тому ми вивели NETFORCE Work на ринок.

Підсумовуючи наш досвід у питанні build vs buy, можу порадити:

• Обирайте готове рішення, якщо: ви тільки стартуєте або ваші процеси не вимагають глибокої кастомізації. Але будьте готові, що під час використання з’являться потреби, які цей софт не закриватиме.
• Створюйте власне рішення, якщо: готовий продукт змушує постійно шукати компроміси або підлаштовуватись під обмеження софту, а вартість доробок стає суттєвою. І, звісно, якщо у вас є достатня технічна експертиза, щоб розробити й надалі підтримувати власне рішення.

Завжди варто зважувати час, ресурси, витрати та те, наскільки ефективно працюють ваші бізнес-процеси з поточним інструментом.

Ми свій вибір зробили, і час показав, що для нас цей шлях виявився правильним.

Буду радий відповісти на запитання в коментарях і дізнатися, як ви вирішуєте питання HR-автоматизації у своїх компаніях.