Как я собирал ERP контур из 5 продуктов для строительной компании

Все схемы и примеры в статье собраны заново на условных данных. Реальные названия, документы и финансовые показатели я здесь не показываю.

Было четкое видение о CEO компании, что бы он хотел видеть в автоматизациях, но все равно пришлось расписывать бизнес‑процессы, что бы четко понимать в какой именно момент была необходима автоматизация.

Итак, у нас есть 2 источника истины, 1С и Bitrix. Во вложениях Bitrix, в одной из заявок, конкретной воронки лежат: договор, счёт, акты. Прописанный, объект в одном месте записан одним названием, в другом, его вообще нет. Ты открываешь несколько окон,1С'ку, Bitrix, реестр оплат, реестр работ по объекту и пытаешься собрать цепочку и в какой‑то момент понимаешь, что сам стал интерфейсом между системами.

Сначала я хотел сделать нормальный реестр оплат. Потом упёрся в договоры. Затем в людей на бэкофисе и задачи сотрудников. Сейчас у меня 5 продуктов, из которых постепенно складывается ERP‑контур для строительной компании. Они, конечно, ещё не превратились в одну бесшовную систему. Однако каждый закрывает понятную часть процесса, и уже видно, как их связывать без фантазии про кнопку «ИИ сделает всё», за 1–2 дня.

Что за 5 продуктов

Финансовое ядро сводит платежи 1С, заявки Bitrix24, документы и сметы. Генератор договоров помогает юридическому отделу подготовить проект Word‑документа, по шаблону и показывает, откуда взялось каждое поле. Сервис учёта времени работает с сотрудниками, сменами, отсутствиями и задачами. Отдельный бот читает рабочую сводку по численности людей на объектах, включая подрядчиков. Пятый продукт, уже про экран руководителя: он берёт короткие сводки из других сервисов, не пытаясь заново реализовать их логику.

Почему это 5 сервисов, а не одна большая база? Потому что «человек вышел на смену», «подрядчик вывел бригаду», «работы приняли актом» и «деньги ушли» — это совершенно разные факты. Если смешать их только потому, что всё относится к одному объекту, получится красивый экран, которому нельзя доверять. (P. S. Красивый экран был, очень долго ломал голову, откуда CEO нарисовал столько метрик)

Представим условный подряд. Инициатор создаёт заявку. Юрист готовит по ней договор. Позже появляются счёт и акты. Финансовый блок связывает эти документы с оплатой. Строительный блок смотрит, сколько людей подрядчик вывел на объект, какой объем закрыл. HR тем временем ведёт собственных сотрудников. Руководитель хочет видеть общую картину. В бизнесе это один процесс. В данных есть несколько контуров, между которыми пока есть и автоматические, и ручные переходы.

Вокруг этой пятёрки у меня есть другие пилотные инструменты: для материалов, графика работ, обращений подрядчиков, контроля техники на объекте и контроля качества. Они пока не дают мне оснований писать, будто весь строительный процесс уже работает в одной ERP. Расскажу про то, что можно показать честно.

Финансы: области тьмы

Мне хотелось открыть объект и сразу увидеть: сколько заложили, сколько законтрактовали, сколько работ приняли и сколько оплатили. Но это не 4 названия одной суммы.

Смета отвечает за план(P. S. если она есть, конечно). Договор, отвечает за обязательства. АВР и КС, отвечает за принятый объём. 1С, отвечает за отражённые платежи. Bitrix24 хранит заявку и контекст согласования. Система должна помнить, откуда взята каждая цифра. Если в заявке стоит стадия «Оплата», это ещё не значит, что деньги уже ушли. Если договора нет в нашей базе, это не доказывает, что его никогда не было.

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

Допустим, в назначении указан условный счёт INV-042. В документах заявки REQ-017 находится тот же номер. Это уже предметная связь. А если, чудесным образом, совпали только название подрядчика и сумма? Я могу предложить заявку как кандидата, но выдавать её за установленный факт опасно. Одинаковые суммы бывают у регулярных услуг, авансов и этапных оплат. В раннем варианте запасной поиск мог выбрать «лучшего» кандидата автоматически; но сейчас, я бы обязательно показывал уровень уверенности и спорные связи отправлял человеку.

Есть и менее очевидная ловушка. Если одна из баз 1С не обновилась(P. S. когда вы работаете с группой компаний), в интерфейсе легко получить «оплачено 0». Для сотрудника это выглядит как доказательство отсутствия оплаты. На самом деле данных просто не хватает. Поэтому вместе с суммой нужно показывать полноту источника.

Когда эти связи появились, накопитель стал для меня чем‑то большим, чем таблица. Открываешь подрядчика, затем видишь заявку, договор, условия, принятый объём и фактические платежи. Из БДДС можно пройти от объекта к виду работ, от него к заявке, а потом к документу. Получается рабочий справочник того, что и когда происходило по конкретному подряду.

Раньше коллеги из ПТО могли тратить на поиск договора или подтверждения оплаты 1–2 часа. С готовой связанной карточкой ответ обычно находился за минуты. Я не проводил эксперимент с секундомером и не называю это измеренной экономией. Это наблюдение по работе и устные отзывы. Но разница в самом действии очевидна: человек уже не собирает накопитель заново из нескольких систем, а проверяет найденную цепочку и при необходимости открывает первоисточник. (P. S. Кстати, вам следует больше сверяться с реестрами, которые ведут реальные люди, например у одного из моих коллег по цеху, был похожий вопрос,«‑ а что, надо нанимать финансового аналитика, что бы понять получившийся мэтчинг верный или нет?». Нет, достаточно перевести данные реестра оплаты, работ, поставок в источник истины, именно тогда и покажутся все расхождения и аномалии.

Договоры: любовь и ненависть

Параллельно появился другой вопрос. Если в Bitrix24 уже есть заявка, зачем юрист каждый раз переносит её данные в шаблон руками?

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

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

Это экономит механическую работу, но не отменяет юридическую. Система готовит проект и справку по спорным полям. Юрист проверяет условия, формулировки и принимает решение: согласовать или вернуть на доработку. На общем экране уже можно увидеть, какие ошибки повторяются при генерации договоров. Связь с сервисом задач сотрудников тоже предусмотрена, но по умолчанию выключена. Я специально различаю эти вещи: готовый договорный генератор, работающая сводка его ошибок и подготовленная интеграция задач, не одна и та же степень готовности. Тем более формирующийся лог с «косячниками», так я назвал базу данных, куда попадают имена и фамилии инициаторов, что в дальнейшем играло роль депремирования, за повторяющиеся ошибки при заполнении заявок bitrix.

Люди: Одисея

Когда я дошёл до людей на объекте, сперва показалось, что нужен один «учёт персонала». Но тут опять два разных вопроса.

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

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

Мне кажется важным не пытаться сразу сложить обе цифры в одно поле «на объекте работают N человек». У них разное происхождение, разная периодичность обновления и разные правила проверки. Общий экран когда‑нибудь может поставить их рядом. Но прежде нужно объяснить пользователю, кого именно считает каждая система.

Документы для оплаты тоже приходится читать с осторожностью

Вернусь к финансовому ядру. Сначала я думал: возьмём договор из Bitrix24, прочитаем и всё. Но в одной заявке бывают договор, допсоглашение, счёт, АВР, КС-2, КС-3. Документ может оказаться не в том поле. Несколько файлов могут быть склеены в один PDF, а один и тот же файл прикреплён дважды.

Поэтому чтение устроено как отдельный процесс: получить вложения, убрать повторы, понять тип документа и извлечь нужные факты. Модель помогает превратить PDF и сканы в структурированные поля: суммы, условия аванса и удержания, принятые объёмы, номера и реквизиты. Мне был нужен именно такой помощник, потому что ручная перекладка данных из документов быстро становится узким местом.

Но фраза «ИИ прочитал договор» сама по себе ничего не гарантирует. Модель может принять сумму акта за сумму договора или пропустить вторую часть объединённого PDF. Поэтому результат должен вести обратно к исходному файлу. Если существенные поля не извлечены, нельзя молча записать пустую карточку и считать заявку проверенной.

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

Упрощённый расчёт доступного остатка такой:

остаток = сумма договора − удержание − бартер − фактически оплачено

Здесь легко ошибиться с авансом: если он уже отражён как платёж в 1С, вычитать его отдельно второй раз нельзя. Сравнение с АВР тоже требует контекста. Оплата без акта может быть договорным авансом. Система должна показать условие и риск человеку, который принимает решение. Дополнительно можно подтянуть сведения о контрагенте из внешнего источника и приложить замечания к карточке заявки.

Зачем понадобился крайний продукт

Когда появились отдельные сервисы, захотелось собрать всё в одном месте. Тут можно было бы создать ещё одну базу и копировать туда все данные. Но тогда пришлось бы поддерживать вторую версию финансовых правил, вторую версию ошибок договора, вторую версию расчёта численности. Я решил оставить ответственность за факты там, где они возникают, а общий экран сделать читателем коротких снимков.

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

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

Где у меня остались прорехи

Главное, наверное, качество связей. Назначение платежа бывает пустым или неоднозначным. Один счёт может оплачиваться частями. Одинаковая сумма может встречаться много раз и не быть дублем. Справочники объектов и подрядчиков тоже не становятся чистыми просто потому, что появился новый интерфейс.

Я бы не оценивал такую систему одной цифрой «сматчили X% платежей». Можно связать много строк и ошибиться в важных случаях. Лучше отдельно смотреть, сколько связей подтверждается однозначным номером, сколько получено эвристикой и сколько осталось на ручной разбор.

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

Если бы начинал следующую итерацию сегодня, я бы раньше занялся общими справочниками объектов и контрагентов, статусом полноты источников и уверенностью в каждой связи. Именно эти скучные вещи определяют, можно ли доверять красивому экрану.

Пока у меня получились пять работающих в разной степени связанных продуктов и понятный маршрут, как превратить их в более цельный ERP‑контур. Самое ценное для меня это возможность дойти от числа на экране до заявки, документа или платежа, на котором это число основано. Когда такой путь есть, автоматизация действительно помогает человеку принимать решение. Когда его нет, это просто ещё одна сводка, которую приходится перепроверять вручную.