Как мы разработали модуль автоматического расчёта KPI и премий в Bitrix24 для строительной компании со ста с лишним сотрудниками: дерево проекта вместо плоского списка задач, распределение денег по иерархии и архитектура, которая переживает смену бизнес-правил.
Автоматизация расчета KPI в Bitrix24 для строительной компании
Практически в каждой компании рано или поздно возникает вопрос: как сделать систему премирования прозрачной, понятной и независимой от человеческого фактора. Пока сотрудников немного, а проектов всего несколько, расчет KPI можно вести вручную — в Excel. Но по мере роста бизнеса такой подход начинает создавать все больше проблем.
Именно с такой ситуацией пришлось столкнуться при разработке данного решения. Компания одновременно вела большое количество строительных проектов, а в работе участвовало более ста сотрудников различных подразделений. Каждый квартал необходимо было определить, кто и какой вклад внес в выполнение проектов, насколько своевременно были закрыты контрольные точки и какую часть премии должен получить каждый участник команды.
Изначально весь процесс строился вокруг электронных таблиц: данные собирались вручную из нескольких источников, объединялись в Excel, после чего выполнялся расчет премий. Даже при наличии готовых формул сотрудники были вынуждены многократно перепроверять результаты — любая ошибка в исходных данных автоматически приводила к неправильным начислениям.
В качестве основной платформы компания уже использовала Bitrix24, но готового решения для расчета KPI с учетом сложной структуры проектов, распределения ответственности между несколькими исполнителями и отраслевых правил начисления премий платформа не предлагает. Отдельные элементы можно было бы реализовать через штатные бизнес-процессы и роботов, но с каждым новым исключением такой набор сценариев становился бы все сложнее поддерживать — а в реальных строительных проектах исключения появляются постоянно.
Поэтому было принято решение разработать отдельный модуль, полностью интегрированный в коробочную версию Bitrix24. Его задача — не просто выполнить математические расчеты, а автоматически собирать данные из разных разделов системы, анализировать структуру проекта, рассчитывать вклад каждого сотрудника и формировать итоговые начисления, сохраняя при этом прозрачность всех промежуточных вычислений. Цель была не переложить Excel-таблицу внутрь Bitrix24, а полностью убрать из процесса ручной перенос данных и поиск ошибок в формулах.
Почему расчет KPI оказался сложнее, чем кажется
На первый взгляд задача выглядит просто: есть проект, список сотрудников, список задач и сумма, которую нужно распределить между участниками. Кажется, достаточно посчитать процент выполненных задач и начислить каждому пропорциональную премию. На практике эта схема ломается почти сразу.
Строительный проект — это не набор независимых задач, а взаимосвязанная иерархия: объект строительства, этапы реализации, контрольные точки и конкретные производственные задачи. Одни работы невозможно начать до завершения других, часть выполняется параллельно, а в одной контрольной точке одновременно участвуют специалисты разных подразделений. Именно поэтому расчет строится не вокруг отдельных задач, а вокруг дерева проекта, где каждая вершина влияет на итоговый результат.
Одной закрытой задачи недостаточно, чтобы оценить вклад сотрудника
Значение имеет сразу несколько факторов: насколько важна была сама задача для проекта, сколько сотрудников участвовало в ее выполнении, какая доля ответственности приходилась на каждого, была ли соблюдена контрольная дата и какое финансовое значение имеет данный этап. Две задачи, закрытые в один день, могут иметь совершенно разный вес — одна второстепенная организационная работа, другая завершает крупный этап, после которого компания получает платеж от заказчика.
Поэтому вместо универсальной формулы каждая задача получает собственный вес, а итоговая оценка складывается из нескольких независимых факторов. Важно, что вес — это не фиксированное число, а величина относительно соседних задач одного уровня дерева. Такой механизм устойчив к изменениям: при добавлении новых задач или изменении структуры проекта пересчитываются только веса внутри соответствующего участка дерева, а не вся модель целиком.
Деньги нельзя разделить поровну, а формулы нельзя зафиксировать раз и навсегда
В строительной отрасли почти всегда есть дополнительные правила начислений: часть суммы резервируется на уровне проекта, часть относится к ответственности руководителя, некоторые работы имеют повышающий коэффициент. Поэтому модуль не делит общую сумму проекта между исполнителями напрямую — он последовательно распределяет финансовые показатели сверху вниз по всей структуре проекта, на каждом уровне учитывая действующие бизнес-правила.
При этом сами правила расчета не остаются неизменными: появляются исключения, корректируются коэффициенты, меняются внутренние регламенты. Если вся логика сосредоточена в одной большой функции, любое изменение превращается в риск задеть смежное правило. Поэтому расчет KPI построен не как одна формула, а как последовательность независимых этапов обработки: получение данных, построение структуры проекта, вычисление весов, распределение финансовых показателей, расчет итогового KPI. Каждый этап отвечает только за свою часть и может дорабатываться отдельно от остальных.
Архитектура: конвейер этапов вместо одной большой формулы
Любой разработчик, впервые сталкиваясь с такой задачей, приходит к очевидной идее — написать одну функцию, которая последовательно загрузит задачи, рассчитает веса, распределит деньги и вычислит KPI. Такой подход удобен ровно до первого изменения бизнес-правил, после которого единая функция начинает обрастать условиями и превращается в код, в котором сложно разобраться.
Поэтому расчет реализован как конвейер, где каждый этап знает только о своей задаче и ничего не знает о внутренней реализации остальных.
- Получение исходных данных. Структура проекта и дерево задач из Bitrix24, настройки весов и распределения ответственности, финансовые показатели за расчетный период — все эти данные никак не связаны между собой и на первом этапе объединяются в единую модель.
- Построение структуры проекта. Плоский список задач Bitrix24 преобразуется в иерархию: объект → этапы → контрольные точки → задачи исполнителей. Это отражает реальную организацию проекта и позволяет анализировать не отдельные задачи, а проект целиком.
- Определение значимости каждого элемента. Веса задач рассчитываются относительно соседей одного уровня дерева, а не как абсолютные коэффициенты.
- Распределение финансовых показателей. Общая сумма проекта постепенно «спускается» вниз по дереву — от этапа к контрольной точке, от нее к задаче и исполнителям, с учетом бизнес-правил на каждом уровне.
- Расчет итогового KPI. Финальный шаг опирается на уже готовые структуру, веса и распределенные суммы, поэтому представляет собой логическое завершение предыдущей обработки, а не отдельный набор вычислений.
Главное преимущество такого разделения — не читаемость кода, а возможность менять каждый этап независимо от остальных. Если меняются правила распределения денег, дорабатывается только соответствующий этап. Если появляется новый источник данных, изменения затрагивают только его получение. Именно благодаря такой изоляции модуль постепенно развивался без необходимости переписывать его целиком — для долгоживущих корпоративных решений это важнее, чем экономия времени на первой версии.
Надежность расчетов и разные представления для ролей
Автоматизировать вычисления — только половина задачи. При работе с крупными проектами и несколькими сотнями пользователей не менее важна предсказуемость поведения системы в реальных условиях эксплуатации.
Блокировка проекта на время расчета
Если два руководителя одновременно запустят расчет KPI по одному проекту, оба процесса могут начать изменять одни и те же данные параллельно — такие ситуации сложно воспроизвести и еще сложнее объяснить задним числом. Поэтому во время расчета проект временно блокируется: повторный запуск становится недоступен до завершения текущего, после чего блокировка снимается автоматически. Для пользователя это практически незаметно, но именно это гарантирует целостность результата.
Расчет и начисление — разные операции
Сразу превращать результат вычисления в итоговые выплаты рискованно: после расчета руководители обычно анализируют результаты, проверяют распределение показателей и обсуждают спорные ситуации. Поэтому модуль сначала формирует предварительный расчет, который можно изучить, сравнить с предыдущими периодами и пересчитать после изменения исходных данных — и только после подтверждения руководителем результаты фиксируются как основание для выплат.
Даже зафиксированный результат можно отменить: если после закрытия квартала обнаруживаются уточненные финансовые показатели или закрываются ранее незавершенные задачи, проект снова становится доступен для повторного расчета — без ручных корректировок в базе данных.
Один расчет, разные представления данных
Сотрудник, руководитель и администратор работают с одним и тем же результатом расчета, но видят разный объем информации. Сотрудник видит только свои задачи, KPI и начисления. Руководитель дополнительно видит показатели своей команды и может оценивать вклад каждого участника. Администратор имеет доступ к полной структуре проектов и настройкам весов и правил расчета. При этом KPI не пересчитывается заново под каждую роль — логика расчета существует в одном экземпляре, а меняется только способ представления результата, что исключает расхождения между интерфейсами.
Нюансы, которые редко попадают в техническое задание
Значительная часть времени при разработке подобных систем уходит не на основной алгоритм, а на детали, которые не видны пользователю за кнопкой «Рассчитать KPI».
- Квартал — не всегда календарный. Внутри компании границы кварталов исторически определялись особенностями финансового учета и регламентами сдачи объектов, а не календарем. Модуль считает по периодам, принятым в организации, а не по общепринятым датам — иначе результаты разойдутся с уже существующей системой учета.
- Данные приходят не одновременно. Задачи закрываются сразу, а финансовые показатели могут появиться только через несколько дней после конца отчетного периода. Из-за этого понятия предварительного расчета и окончательной фиксации разделены — иначе есть риск посчитать премии по неполным данным.
- Повторный расчет — штатная операция, а не аварийная процедура. Изменились финансовые показатели, скорректировалась структура задач, нашлась ошибка в исходных данных — любой из этих случаев требует пересчета. Система спроектирована так, чтобы при одинаковых исходных данных всегда получать одинаковый результат, независимо от количества запусков.
- Автоматизация не отменяет контроль. Модуль не пытается скрыть внутреннюю логику — пользователь может проследить, как сформировался итоговый показатель и какие данные в этом участвовали. Для системы мотивации это критично: доверие к автоматизированному расчету напрямую зависит от того, можно ли объяснить происхождение каждой цифры.
Итоги проекта
Разработка модуля позволила полностью отказаться от ручного расчета KPI в Excel. Вместо процесса из множества промежуточных файлов и повторных пересчетов компания получила единый механизм внутри Bitrix24, который сам собирает структуру проекта, учитывает финансовые показатели, распределяет ответственность между исполнителями и формирует начисления — при этом каждый этап остается прозрачным и проверяемым.
Основная сложность проекта была не в программировании — получить список задач или вывести данные в интерфейс Bitrix24 решается стандартными средствами платформы. Настоящая работа заключалась в том, чтобы превратить неформализованные бизнес-правила компании в алгоритм, который работает автоматически и одинаково для любого, кто его запускает. Именно поэтому такие модули редко сводятся к нескольким формулам: за простым интерфейсом стоит система, объединяющая задачи, финансовые показатели, организационную структуру и внутренние правила мотивации в единый воспроизводимый процесс.