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