Уявіть велику організацію зі складною структурою. Щодня співробітники виходять на роботу, їдуть у службові відрядження, беруть лікарняні, повертаються з відпусток або переходять між підрозділами. Усі ці зміни потрібно врахувати в табелі, документах і звітах. Коли кожен підрозділ веде власний Excel-файл, швидко з’являються дублікати, різні формати й кілька версій одних даних.
З такою ситуацією до нашої команди звернулася велика організація з розгалуженою багаторівневою структурою (під NDA). Облік співробітників був розподілений між таблицями та документами, а зведені дані доводилося збирати вручну. Потрібна була єдина система, яка підтримує складну ієрархію, працює в реальному часі та відповідає високим вимогам до безпеки даних.
Результатом стала Enterprise HRM-система: 17 функціональних модулів, близько 93 тисяч рядків коду, 60+ моделей даних і 200+ API-ендпоінтів. Це робоча платформа для щоденного обліку співробітників, документів, статусів і доступів.
Технічний опис зібрано окремо в кейсі Enterprise HRM-системи в портфоліо. Якщо вам потрібна автоматизація власних кадрових процесів, дивіться також послугу розробки HRM-систем.
Нижче розбираємо, як побудована система, які модулі закрили ручні операції та що довелося врахувати в архітектурі.
Виклик: чому Excel не працює на великому масштабі
Для невеликої команди таблиці можуть бути достатнім інструментом. У великій структурі з багатьма підрозділами вони стають джерелом постійної ручної роботи. На старті проєкту ми побачили кілька системних проблем.
Немає єдиної бази. Кожен підрозділ вів облік окремо. Дані дублювалися, конфліктували та втрачали актуальність. Щоб отримати зведений звіт, відповідальним працівникам доводилося збирати файли й вручну узгоджувати розбіжності.
Табель складно підтримувати. Статуси співробітників змінюються щодня, а кожна пропущена відмітка впливає на документи та підсумкові звіти. Ручне заповнення потребувало повторних перевірок і не давало надійного зв’язку з кадровими подіями.
Документообіг залежить від копіювання. Звіти, довідки та внутрішні форми створювалися з попередніх файлів. Разом із шаблоном легко перенести застарілі реквізити або дані іншого співробітника.
Немає повної історії змін. У таблиці важко встановити, хто оновив запис, коли це сталося і яким було попереднє значення. Пошук джерела помилки займав більше часу, ніж саме виправлення.
Високі вимоги до безпеки даних. Потрібні ізоляція на рівні бази, рольовий доступ і аудит дій. Файли в локальних папках або месенджерах не дають такого контролю.
За такого набору вимог кастомна розробка була практичним рішенням. Систему потрібно було будувати навколо процесів організації, а не підлаштовувати ці процеси під обмеження готового продукту.
Що ми побудували: огляд HRM-системи
Основний стек: Django REST Framework на бекенді, React + TypeScript на фронтенді та PostgreSQL з Row-Level Security для зберігання даних. Оновлення передаються через WebSocket у реальному часі. Платформа має модульну архітектуру, тому окремі процеси можна розвивати без переробки всієї системи. Про вибір технології ми докладніше писали у статті чому ми використовуємо Django.
Нижче сім модулів і технічних рішень, які найкраще показують логіку платформи.
1. Організаційна структура
Замість жорстко заданих рівнів, наприклад департамент, відділ, група, команда, ми побудували гнучке дерево з необмеженою глибиною. Для роботи з ієрархією використали django-mptt. Адміністратор може додавати типи підрозділів, переміщувати гілки та змінювати підпорядкування без правок у коді.
Кожен вузол дерева пов’язаний із посадами, категоріями посад і співробітниками. React Flow допомагає показувати складні зв’язки в інтерфейсі. Така модель не фіксує організацію в одній схемі й підтримує зміни структури в межах самої системи.
2. Табель для великої структури
Табель зводить щоденні статуси співробітників: робота на місці, службове відрядження, лікарняний, відпустка або навчання. Дані потрібно швидко переглядати, редагувати, фільтрувати та використовувати у звітах.
Інтерфейс показує потрібний фрагмент табеля, а дані зберігаються в PostgreSQL і доступні через окремий API-модуль. Для подальшої роботи передбачено Excel-експорт.
Табель може заповнюватися автоматично за правилами маппінгу. Коли адміністратор змінює статус співробітника, система ставить відповідну відмітку. Одна подія не потребує повторного введення в кількох місцях.
3. EAV-конструктор полів і статусів
Склад картки співробітника змінюється залежно від підрозділу та процесу. Щоб не додавати кожне нове поле через реліз, ми реалізували EAV-конструктор. Адміністратор створює текстові, числові, датовані поля, списки та множинний вибір через інтерфейс.
За таким самим принципом працюють статуси. Для нового статусу можна задати назву, колір, доступність для ролей і зв’язок із табелем. Зміна стає доступною без окремої доробки бекенду.
Для залежних сценаріїв є конструктор умов. Наприклад, статус службового відрядження змінює відмітку в табелі, оновлює пов’язане поле та надсилає повідомлення відповідальному керівнику.
4. Генерація документів із шаблонів
Система формує DOCX-документи з підготовлених шаблонів і даних із бази. Звіт, довідка або внутрішня форма заповнюються актуальними реквізитами без ручного копіювання. Реєстри можна вивантажити в Excel.
Оператор працює з одними й тими самими даними в картці співробітника, табелі та документах. Це приклад автоматизації, яка прибирає дублювання дій із щоденного процесу.
5. Журнал операцій і drag-and-drop конструктор звітів
Журнал операцій поєднано з конструктором звітів. Користувач збирає форму з блоків: текстових полів, таблиць із даними, підписів і позначок часу. Блоки переміщуються через drag-and-drop, а готовий звіт зберігається разом з історією дій.
6. WhatsApp-бот і Google Sheets
WhatsApp-бот надсилає службові повідомлення, нагадування та сповіщення про зміну статусу. Інтеграція з Google Sheets потрібна підрозділам, які продовжують працювати з таблицями: система передає актуальні дані й приймає погоджені оновлення без ручного перенесення.
7. Адмін-панель із моніторингом
В окремій панелі адміністратор бачить активні WebSocket-з’єднання, журнал дій і налаштування ролей. Близько 30 гранулярних дозволів визначають доступ до модулів, операцій і окремих наборів даних.
Технічні виклики: як забезпечити масштаб і безпеку
Розробка масштабної системи для великої організації вимагає не більшої кількості форм, а чітких меж між модулями, контрольованого доступу до даних і передбачуваної роботи інтерфейсу. Основні виклики були пов’язані з обсягом моделі даних, синхронізацією та ізоляцією.
Продуктивність на великих масивах даних
17 модулів, 60+ моделей даних і 200+ API-ендпоінтів не можна обслуговувати як один великий блок. Ми розділили запити за функціональними зонами, а доступ до записів обмежили контекстом ролі та гілки організаційного дерева.
django-mptt відповідає за роботу з ієрархією, PostgreSQL зберігає зв’язки й табель, а React завантажує дані для поточного екрана. Такий поділ не змушує інтерфейс щоразу обробляти всю структуру.
Реальний час через WebSocket
Коли оператор змінює статус співробітника, пов’язані екрани мають отримати оновлення без повторного відкриття сторінки. WebSocket передає подію підписаним клієнтам у реальному часі.
Адмін-панель показує активні з’єднання та модулі, з якими вони працюють. Це допомагає бачити стан системи й розбиратися з проблемами синхронізації.
Три рівні ізоляції даних
Високі вимоги до безпеки даних закладені в архітектуру. Ізоляція працює на трьох незалежних рівнях:
- Рівень ORM у Django: запити фільтруються за доступною користувачеві частиною структури.
- Рівень middleware і ролей: кожна операція проходить перевірку дозволів до виконання бізнес-логіки.
- Рівень PostgreSQL RLS: база додатково обмежує рядки на рівні SQL.
Рольовий доступ, ізоляція на рівні бази та аудит дій доповнюють одне одного. Помилка в одному шарі не повинна автоматично відкривати дані іншого підрозділу.
Повний аудит дій
Кожна значуща зміна потрапляє в журнал: хто виконав дію, коли вона відбулася, яке значення було до зміни і яким стало після. Історію можна перевірити без пошуку копій файлів або листування між співробітниками.
Ключові результати: що змінилося для клієнта
Після впровадження системи організація отримала єдиний робочий контур для даних про співробітників і пов’язаних операцій.
Єдина база замість розрізнених файлів. Зведені звіти формуються з актуальних записів. Підрозділам не потрібно зводити окремі версії таблиць вручну.
Табель заповнюється за правилами. Статуси співробітників пов’язані з відмітками, тому одна зміна відображається в потрібних частинах системи.
Документи генеруються з актуальних даних. Шаблони отримують реквізити з бази, а реєстри доступні через Excel-експорт.
Доступ і дії контролюються. Близько 30 дозволів, три рівні ізоляції даних і журнал змін дають зрозумілу картину того, хто працював із записом.
Структура змінюється без доробки коду. Адміністратор керує деревом підрозділів, полями, статусами та правилами через конструктори.
Оновлення надходять у реальному часі. WebSocket синхронізує пов’язані екрани, а інтеграції передають дані зовнішнім робочим інструментам.
Додаткові технічні деталі є на сторінці Enterprise HRM-кейсу в портфоліо.
Висновок: коли потрібна кастомна HRM-система
Готова HRM-платформа добре працює зі стандартними процесами. Кастомна система потрібна, коли структура, доступи та документообіг не вкладаються в наперед задану модель.
- Складна організаційна структура з багаторівневим деревом і різними правилами для підрозділів
- Високі вимоги до безпеки даних, включно з рольовим доступом, аудитом дій та ізоляцією на рівні бази
- Власні бізнес-процеси, які потребують гнучких полів, статусів і сценаріїв
- Інтеграції з внутрішніми системами, месенджерами, таблицями та документами
- Часті зміни структури, які адміністратор має вносити без участі розробника
Якщо ці умови збігаються з вашою ситуацією, варто почати з опису ролей, дерева підрозділів і поточних джерел даних. Це дає достатньо матеріалу, щоб оцінити межі першої версії та перевірити, чи справді потрібна кастомна розробка.
В Artbrain ми розробляємо HRM-системи, CRM, ERP та інші інструменти автоматизації. Якщо готовий продукт не покриває ваш процес, опишіть завдання, і ми розберемо вимоги до структури, доступів та інтеграцій.
Також дивіться розробку бізнес-систем під ключ, послуги розробки та реалізовані проєкти.
Часті питання
Скільки коштує розробка HRM-системи?
Базова HRM-система з обліком співробітників, відпустками та зарплатою – від $3500. Масштабну enterprise-систему з 17 модулями, як у нашому великому кейсі (93K рядків коду, 60+ моделей даних), оцінюємо індивідуально після брифу. Ціна залежить від кількості модулів, інтеграцій та навантаження.
Чи може HRM-система працювати з великою кількістю користувачів?
Так, при правильній архітектурі. Наша enterprise HRM-система — це 93K рядків коду, 60+ моделей даних, 200+ API-ендпоінтів та real-time оновлення через WebSocket. Ключове – Django + PostgreSQL забезпечують масштабованість, а React – швидкий інтерфейс.
Які модулі потрібні для HRM-системи?
Базові: облік співробітників, організаційна структура, відпустки, зарплата. Розширені: KPI-метрики, рекрутинг, навчання, табелі, документообіг, штатний розпис. Модулі додаються поступово без переписування коду.
