Представьте крупную организацию со сложной структурой. Каждый день сотрудники выходят на работу, уезжают в служебные командировки, берут больничные, возвращаются из отпусков или переходят между подразделениями. Все эти изменения нужно учитывать в табеле, документах и отчётах. Когда каждое подразделение ведёт собственный 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-система работать с большим количеством пользователей?
Да, при правильной архитектуре. Наша enterprise HRM-система – это 93K строк кода, 60+ моделей данных, 200+ API-эндпоинтов и real-time обновления через WebSocket. Ключевое – Django + PostgreSQL обеспечивают масштабируемость, а React – быстрый интерфейс.
Какие модули нужны для системы HRM?
Базовые: учет сотрудников, организационная структура, отпуска, заработная плата. Расширенные: KPI-метрики, рекрутинг, обучение, табели, документооборот, штатное расписание. Модули добавляются постепенно без переписки кода.
