Уявіть: у вас велика організація зі складною структурою. Кожен день хтось приходить, хтось іде у відрядження, хтось на лікарняному, хтось переводиться з одного підрозділу до іншого. А ви все це ведете в Excel. Точніше, не ви один – а різні підрозділи, кожен у своєму файлі, зі своїм форматуванням, своїми помилками та своїми версіями правди.
Саме з такою ситуацією до нашої команди звернувся клієнт – державна оборонна структура, де облік особового складу вівся переважно вручну, в розрізнених таблицях і документах. Завдання було чітке: побудувати єдину систему, яка замінить хаос на порядок. Без компромісів у безпеці, без обмежень у масштабуванні, і з можливістю працювати в реальному часі.
Результат – HRM-система: 93 тисячі рядків коду, 17 функціональних модулів, 80+ API ViewSets, 11 Django-додатків. І головне – вона реально працює щодня.
У цьому кейсі ми розповімо, як будували систему від нуля, з якими технічними викликами зіткнулися, і чому готові рішення тут не підходили.
Виклик: чому Excel не працює на великому масштабі
Коли організація невелика, Excel – це нормально. Може, навіть зручно. Але зі складною структурою і багатьма підрозділами Excel перетворюється на ворога. Ось конкретні проблеми, з якими жив клієнт:
Немає єдиної бази. Кожен підрозділ вів свій облік. Дані дублювалися, конфліктували, губилися. Щоб зібрати зведений звіт по всій організації, потрібно було вручну збирати файли і зводити їх в один документ.
Табель – це кошмар. Коли табель ведеться вручну для великої структури, кількість записів швидко стає некерованою. Кожна помилка у відмітці – це невірні розрахунки, некоректні звіти і додаткова ручна перевірка.
Документообіг – суцільне ручне заповнення. Накази, рапорти, довідки – все писалося вручну або копіювалося з попередніх документів з ризиком залишити чужі дані. Система автоматизує цю рутину і зменшує кількість ручних помилок.
Відсутність контролю та прозорості. Хто вніс зміни? Коли? Які дані були до зміни? Ніхто не знав. Аудит-трейл був відсутній. Якщо виникала помилка, знайти її джерело було практично неможливо.
Безпека – формальна. Файли ходили по месенджерах, зберігалися на локальних комп'ютерах, доступ до них мали всі, кому «кинули файл». Для оборонної структури це критично неприйнятно.
Це саме той випадок, коли кастомна розробка – не примха, а необхідність. Жодне готове рішення не покриває такий набір вимог.
Що ми побудували: огляд HRM-системи
Технологічний стек: Django REST Framework на бекенді, React 18 + TypeScript на фронтенді, PostgreSQL як основна база даних, Redis для кешування та черг, WebSocket для комунікації в реальному часі. Система замінила старий монолітний додаток на Django і стала повноцінною платформою з модульною архітектурою. Детальніше про те, чому ми обрали саме Django – ми писали в окремій статті.
Ось ключові модулі, на яких варто зупинитися детальніше:
1. Організаційна структура (дерево ШПС)
Замість жорстко закодованих рівнів ієрархії (бригада – батальйон – рота – взвод) ми побудували гнучке дерево з необмеженою глибиною вкладеності. Адміністратор може додавати нові типи підрозділів, переміщувати вітки, змінювати ієрархію – без участі розробника. Кожен вузол дерева – це підрозділ із власним набором посад, штатних місць і прив'язаних до нього людей.
Це критично важливо для оборонної структури, де організаційна ієрархія змінюється значно частіше, ніж у цивільних організаціях. Подібний підхід ми використовуємо і при розробці CRM-систем та ERP-рішень – гнучка структура, яка адаптується під клієнта.
2. Табель обліку для великої структури
Це серце системи. Табель показує, де кожна людина перебуває кожного дня: на місці, у відрядженні, на лікарняному, у відпустці, в бойовому завданні. Це масив, який потрібно не просто зберігати, а швидко рендерити, редагувати та будувати на його основі звіти.
Ми використали помісячне партиціонування PostgreSQL: таблиця табелю розбивається на окремі розділи по місяцях. Фронтенд рендерить табель з віртуалізацією – показує лише видимі рядки.
Більше того, табель заповнюється автоматично. Адміністратор налаштовує правила маппінгу: якщо людина отримала статус «Відрядження», у табелі з'являється відповідна відмітка. Це усуває ручне введення і помилки.
3. Конструктор довільних полів та статусів
Одна з найцікавіших архітектурних рішень. Замість того, щоб захардкодити всі можливі поля для картки особи (а їх можуть бути десятки: від групи крові до номера жетону), ми створили конструктор. Адміністратор через інтерфейс додає нові поля: текстові, числові, дата, вибір зі списку, множинний вибір – будь-які.
Так само працює конструктор статусів. Потрібен новий статус «Курси підвищення кваліфікації»? Адміністратор створює його сам, налаштовує колір, іконку, прив'язку до табелю – і він одразу доступний у системі. Не потрібно чекати нову версію від розробника.
А для складних сценаріїв є конструктор умов (Condition Builder): каскадні зміни статусів, коли один статус автоматично впливає на інші поля чи статуси. Наприклад, статус «Госпіталізація» автоматично змінює відмітку в табелі та надсилає повідомлення командиру підрозділу.
4. Генерація документів із шаблонів
Система генерує документи у форматі DOCX за наперед підготовленими шаблонами. Рапорт, наказ, довідка – оператор натискає кнопку, і документ заповнюється автоматично даними з бази. Щоденний рапорт, реєстр в Excel, розрахунки виплат – все формується за секунди.
Замість ручного збирання звітів оператор натискає кнопку, і система формує документ з актуальних даних. Це приклад автоматизації, яка прибирає рутину з щоденної роботи.
5. Бойовий журнал (Drag-and-Drop конструктор звітів)
Унікальний модуль, якого немає в жодній комерційній HRM-системі. Бойовий журнал – це конструктор звітів із drag-and-drop інтерфейсом, де командир будує звіт, перетягуючи блоки: текстові поля, таблиці з даними з бази, підписи, позначки часу. Кожен звіт зберігається з повним аудит-трейлом.
6. WhatsApp-інтеграція та Google Sheets
Система інтегрована з WhatsApp для автоматизованих розсилок: повідомлення про зміну статусу, нагадування, вітання з днем народження. Ми маємо великий досвід у розробці Telegram та чат-ботів, і ці ж підходи застосували для WhatsApp-інтеграції. Також є синхронізація з Google Sheets для підрозділів, які звикли працювати з таблицями – дані автоматично оновлюються в обох напрямках.
7. Адмін-панель із моніторингом
Окрема панель для системного адміністратора: моніторинг серверів, управління резервними копіями, перегляд активних WebSocket-з'єднань (хто зараз онлайн), логи дій, управління правами доступу. RBAC-система з 30+ дозволами дозволяє точно налаштувати, хто що бачить і що може робити.
Технічні виклики: як забезпечити масштаб і безпеку
Розробити масштабну систему для великої організації – це не просто «зробити більше полів у формі». Це принципово інші вимоги до архітектури. Ось головні виклики, з якими ми зіткнулися:
Продуктивність на великих масивах даних
Великі таблиці табелю не можна просто закинути в одну таблицю і робити SELECT без оптимізації. Ми впровадили помісячне партиціонування PostgreSQL, оптимізували індекси, налаштували кешування частих запитів через Redis.
На фронтенді ми використали віртуалізацію списків (React Virtualized), lazy loading та оптимістичні оновлення UI, щоб користувач не відчував затримок навіть при роботі з великими масивами даних.
Реальний час через WebSocket
Коли один оператор змінює статус людини, всі інші користувачі повинні побачити це миттєво. Ми реалізували повноцінну WebSocket-архітектуру: зміни транслюються всім підписаним клієнтам у реальному часі. Це не polling кожні 5 секунд – це справжній real-time.
Адмін-панель показує, скільки користувачів зараз онлайн, в яких підрозділах вони працюють, і які дії виконують. Це критично важливо для розуміння навантаження та оперативного реагування.
Три рівні ізоляції даних
Для оборонної структури безпека – це не «приємно мати», а абсолютна вимога. Ми реалізували три рівні захисту:
- Рівень ORM (Django): кожен queryset автоматично фільтрується за підрозділом користувача. Неможливо випадково запитати дані чужого підрозділу.
- Рівень Middleware: додаткова перевірка прав на кожному запиті, незалежно від ORM. Навіть якщо розробник допустить помилку в коді, middleware не пропустить неавторизований доступ.
- Рівень PostgreSQL RLS (Row Level Security): база даних сама фільтрує рядки на рівні SQL. Навіть якщо зловмисник отримає прямий доступ до бази через SQL-клієнт, він побачить лише дані свого підрозділу.
Три незалежних рівня – це надлишково для більшості проєктів. Але для оборонної структури це мінімум.
Повний аудит-трейл
Жоден запис у системі ніколи не видаляється фізично. Кожна зміна логується: хто, коли, що змінив, які дані були до і після зміни. Це не лише вимога безпеки – це юридична необхідність. Будь-яку дію можна відтворити та перевірити навіть через роки.
Ключові результати: що змінилося для клієнта
Після впровадження «Варти» організація отримала те, чого раніше просто не існувало:
Єдина база замість розрізнених файлів. Зведений звіт по всій організації формується з актуальних даних. Дані не дублюються і не конфліктують.
Табель ведеться автоматично. Оператори більше не заповнюють рядки вручну. Статуси маппляться на відмітки табелю за правилами, які налаштовує адміністратор.
Документи генеруються автоматично. Щоденний рапорт формується з даних системи. Один натиск кнопки – і готовий DOCX-файл.
Прозорість і контроль. Повний аудит-трейл, RBAC з 30+ дозволами, три рівні ізоляції даних. Керівництво точно знає, хто, коли і що робив у системі.
Гнучкість без розробника. Нові поля, нові статуси, нові правила маппінгу – все це адміністратор налаштовує сам через конструктори. Система адаптується до змін організаційної структури без участі нашої команди.
Реальний час. Зміни видно миттєво всім користувачам. Немає затримок, немає розсинхронізації, немає «я ще не зберіг файл».
Подивитися сторінку проєкту з технічними деталями можна у нашому портфоліо – HRM-кейс.
Висновок: коли потрібна кастомна HRM-система
Ринок HRM-систем великий: є хмарні платформи, коробкові продукти та локальні рішення. Але є ситуації, коли готові рішення не підходять:
- Складна організаційна структура з комплексною ієрархією, де стандартні системи не покривають процеси
- Специфічні вимоги до безпеки, як в оборонному секторі, де потрібна ізоляція даних на рівні бази
- Унікальні бізнес-процеси, які неможливо вмістити в рамки готового рішення без болючих компромісів
- Необхідність інтеграції з внутрішніми системами, месенджерами, специфічними форматами документів
- Потреба в гнучкості, коли структура організації змінюється часто і непередбачувано
Якщо ви впізнали свою ситуацію хоча б у двох пунктах – вам, швидше за все, потрібна кастомна розробка. Це більша інвестиція на старті, ніж підписка на SaaS, але в довгостроковій перспективі – це система, яка працює саме так, як потрібно вашій організації.
Ми в Artbrain спеціалізуємося на розробці складних бізнес-систем: замовити HRM під ключ, CRM, ERP та інших рішень для автоматизації. Якщо у вас є завдання, яке не вирішується коробковим продуктом, – залишіть заявку на безкоштовну консультацію. Проаналізуємо вашу ситуацію і чесно скажемо, чи потрібна вам кастомна розробка, чи можна обійтися готовим рішенням.
Замовити розробку бізнес-системи під ключ – HRM від $3 500, CRM від $3 000, ERP від $8 000. Безкоштовна консультація, прозора ціна.
Детальніше про наші послуги розробки під ключ та реалізовані проєкти.
Часті питання
Скільки коштує розробка HRM-системи?
Базова HRM-система з обліком співробітників, відпустками та зарплатою – від $3500. Масштабна enterprise-система з 17 модулями, як у нашому великому кейсі (93K рядків коду, 60+ моделей даних) – від $10000-15000. Ціна залежить від кількості модулів, інтеграцій та навантаження.
Чи може HRM-система працювати з великою кількістю користувачів?
Так, при правильній архітектурі. Наша enterprise HRM-система — це 93K рядків коду, 60+ моделей даних, 200+ API-ендпоінтів та real-time оновлення через WebSocket. Ключове – Django + PostgreSQL забезпечують масштабованість, а React – швидкий інтерфейс.
Які модулі потрібні для HRM-системи?
Базові: облік особового складу, організаційна структура, відпустки, зарплата. Розширені: KPI-метрики, рекрутинг, навчання, табелі, документообіг, штатний розпис. Для військових підрозділів: бойовий склад, переміщення, спецобліки. Модулі додаються поступово без переписування коду.
