Внутренняя ERP для управления командой

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

• Заявки на отпуск и отгул приходили в личные сообщения. Через неделю ни руководитель, ни сотрудник уже не могли восстановить, о чём договорились.
• Остаток отпускных дней считали вручную. При увольнении это регулярно превращалось в спор.
• Часы из трекеров переносили в таблицу копированием — день-два работы в месяц и ошибки переноса.
• Зарплатная ведомость собиралась в таблице: без истории изменений, с формулами, которые ломались при найме и увольнении в середине месяца.
• Праздники, больничные и переработки учитывались по памяти. Доступ к данным о выплатах держался на доверии.

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

Обучать команду не пришлось ни дня. Сотрудник живёт в мессенджере, который у него и так открыт: заявка занимает полминуты, логин и инструкция не нужны. Руководитель согласовывает одной кнопкой прямо в уведомлении. Учиться работе с интерфейсом надо только HR и администраторам — тем, кто и так работает в панели каждый день.

Главное в архитектуре — отсутствие повторного ввода. Одно согласование само обновляет календарь команды, зарплатный лист и баланс отпускных дней, а сотрудник получает ответ в тот же чат, где спрашивал.

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

Остаток отпускных дней ведётся журналом движений, как в бухгалтерии. Каждое изменение баланса — отдельная запись с датой, источником и автором. Раньше остаток хранился одним полем в карточке сотрудника и нигде не считался. Хранить остаток одним числом — типичная архитектурная ловушка B2B-систем: спор при увольнении требует истории, а не числа. Базовая норма — 28 календарных дней.

• Начисление — одна двенадцатая годовой квоты за каждый прошедший месяц, крон отрабатывает первого числа. Пропорция по дням применяется только к году приёма; отсутствия начисление не уменьшают. Наивное округление дало бы за год 27,96 вместо 28, поэтому месяц начисляет разность накопленных округлённых значений: сумма за год равна квоте ровно.
• Списание — FIFO. Правило выбрано в пользу сотрудника: сначала расходуются самые старые дни, поэтому перенесённый остаток уходит раньше свежего начисления и меньше сгорает.
• Перенос и сгорание — отдельные записи журнала: неиспользованный остаток переносится на год, затем сгорает, раз в год по расписанию.
• Корректировка — запись с обязательным комментарием и автором, доступная по отдельному разрешению. В минус баланс не уходит: проверка стоит и в форме, и в сервисе.
• Отпуск сверх остатка заявку не блокирует: дни делятся на оплачиваемую и неоплачиваемую части — оплачиваемые списываются из журнала, неоплачиваемые уменьшают базу без компенсации.

Зарплатный лист создаётся одним действием. Система набирает ростер по всем активным сотрудникам, подтягивает часы из трекеров, согласованные отсутствия, государственные праздники и регулярные надбавки — и считает каждую строку.

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

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

Сотруднику можно открыть расчёт целиком. Тот же расчёт выгружается в PDF для бухгалтерии.

Система сама помечает строки, которые нельзя закрывать не разобравшись: ноль часов у почасового сотрудника, несогласованный отгул внутри периода, отсутствующий курс валюты, фиксированная выплата при наличии отсутствий. У каждого флага — объяснение, что именно не так и как это повлияло на сумму.

Ошибки видны в черновике, до закрытия периода. Это дешевле на порядок.

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

Отдельно — счётчик дней до окончания контракта: на поиск замены остаётся время.

Фактическое время разработки — около 80 человеко-часов. Это примерно две рабочие недели одного разработчика: столько заняли вместе кадры и отсутствия, учёт рабочего времени, расчёт зарплаты, интеграции и отпускной баланс.

Активная фаза — апрель и май: около 60 часов, три четверти всего времени. В них уместилось всё, что считает деньги: ядро расчёта зарплаты, правила оплаты, второй источник часов и внешние интеграции. До неё — примерно 20 часов на каркас, кадры, права, API и учёт времени: двадцать пятого апреля 2026 года в панели появились живые учётные записи, и компания перестала вести кадры в таблицах. После — точечные доработки на уже работающем продукте.

Цифры сняты из истории репозитория: коммиты сгруппированы в рабочие сессии по интервалам между ними, поэтому часы — оценка снизу, а не выгрузка тайм-трекера.

Модули доезжали по мере готовности, а не одним релизом в конце. Влитые pull request приходились на апрель, май и июль, а выкладка на основной ветке каждый раз запускалась вручную. Так можно работать, когда откат на предыдущую версию стоит одну команду, а на каждой ветке идёт конвейер стиль → анализ → тесты, три шага параллельно.

На запуске команда получила не заготовку, а рабочий контур — кадры, отсутствия и учёт времени, — и пользовалась им, пока дописывались правила оплаты, интеграции и отпускной баланс. Обычный для нас порядок: сначала то, чем можно пользоваться завтра, потом то, что считает деньги. Ждать «когда будет готово всё» не пришлось ни дня.

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

Что система приносит за год и за два. Каждый месяц она возвращает HR и бухгалтерии два-четыре полных рабочих дня. За год набегает 24–52 рабочих дня, за два года — от 48 до 105. Вся разработка вместе с интеграциями, отпускным журналом и маршрутизацией уведомлений заняла около 80 человеко-часов — порядка десяти рабочих дней, — поэтому вложенное время возвращается за первые три-пять месяцев работы, а дальше идёт чистый плюс.

Те двадцать часов, что довели систему до запуска, окупились в первый же месяц. Дальше эффект только накапливается: система продолжает возвращать те же два-четыре дня ежемесячно, пока компания ей пользуется. Счёт идёт во времени, поэтому цифры переносятся на любую компанию: подставьте свои ставки, и получится сумма.

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

Три приёма, которыми это сделано:

• Система решает за человека всё, что может решить сама. Рабочие дни, государственные праздники по стране сотрудника и курс валюты подставляются автоматически. Спрашивают только то, что действительно требует решения человека.
• Подсказка приходит в момент решения. Остаток дней и пересечения с отпусками коллег показаны прямо в заявке, там, где решение принимается. Искать их в отдельном отчёте не нужно.
• Ошибки ловит система. Ноль часов у почасового, несогласованный отгул, отсутствующий курс — всё это помечено в черновике. Не нужно помнить чек-лист проверок перед закрытием месяца.

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