Когда говорят «ERP система для строительной компании», обычно представляют одну большую программу, которая знает всё: деньги, договоры, людей и объекты. В статье на Хабре «Как я собирал ERP контур из 5 продуктов для строительной компании» автор описывает другой путь. Он не покупал коробку и не строил монолит. Он собрал контур из пяти отдельных сервисов поверх 1С и Bitrix24.
Материал оформлен как кейс, читается минут за девять. Все схемы и примеры автор собрал заново на условных данных: реальных названий, документов и финансовых показателей в статье нет. Зато в ней подробно описано, где такие системы ломаются и почему красивому экрану руководителя нельзя верить без проверки.
Ниже конспект: из чего состоит контур, как устроен поиск связей между платежами и документами, зачем разделять людей своих и подрядных, и что автор считает прорехами. В конце моё мнение отдельным разделом.
Как устроена ERP система для строительной компании: пять продуктов вместо одной базы
Исходная точка знакомая. В компании два источника истины: 1С и Bitrix24. В одной заявке Bitrix24 лежат договор, счёт и акты. Объект в одной системе записан одним названием, а в другой его нет вовсе. Сотрудник открывает 1С, Bitrix24, реестр оплат и реестр работ по объекту и пытается собрать цепочку вручную. Автор формулирует это так: в какой-то момент понимаешь, что сам стал интерфейсом между системами.
У CEO было чёткое видение, что он хочет видеть. Бизнес-процессы всё равно пришлось расписывать, чтобы понять, в какой момент нужна автоматизация. Автор начинал с реестра оплат, потом упёрся в договоры, затем в людей на бэкофисе и задачи сотрудников. Так набралось пять продуктов:
- Финансовое ядро. Сводит платежи из 1С, заявки Bitrix24, документы и сметы.
- Генератор договоров. Готовит для юристов проект Word-документа по шаблону и показывает, откуда взято каждое поле.
- Сервис учёта времени. Сотрудники, смены, отсутствия, задачи.
- Бот численности. Читает рабочую сводку о том, сколько людей на объектах, включая подрядчиков.
- Экран руководителя. Берёт короткие сводки из остальных сервисов и не пересчитывает их логику заново.
Почему пять сервисов, а не одна база? По словам автора, «человек вышел на смену», «подрядчик вывел бригаду», «работы приняли актом» и «деньги ушли» — разные факты. Если смешать их только потому, что всё относится к одному объекту, получится красивый экран, которому нельзя доверять. Автор вспоминает, что такой экран у CEO действительно был, и долго разбирался, откуда там столько метрик.
В бизнесе подряд выглядит как один процесс: заявка, договор, счёт, акты, оплата, люди на объекте. В данных это несколько контуров, и между ними пока есть как автоматические, так и ручные переходы. Вокруг пятёрки у автора есть пилотные инструменты для материалов, графика работ, обращений подрядчиков, контроля техники и контроля качества. Он прямо говорит, что они не дают оснований заявлять, будто весь строительный процесс уже работает в одной ERP.
Финансовое ядро: матчинг платежей и честное «данных не хватает»
Автор хотел открыть объект и сразу увидеть, сколько заложили, сколько законтрактовали, сколько работ приняли и сколько оплатили. Оказалось, что это не четыре названия одной суммы, а четыре разных слоя:
| Источник | За что отвечает |
|---|---|
| Смета | план (если она вообще есть) |
| Договор | обязательства |
| АВР и КС | принятый объём работ |
| 1С | отражённые платежи |
| Bitrix24 | заявка и контекст согласования |
Отсюда первое правило: система должна помнить, откуда взята каждая цифра. Стадия «Оплата» в заявке не значит, что деньги ушли. Отсутствие договора в базе не доказывает, что договора не было.
Самой неприятной задачей автор называет матчинг, то есть поиск связи от платежа к заявке, счёту, договору, объекту и виду работ. Если номер заявки указан в назначении платежа, всё просто. Но там бывает номер счёта, кусок названия подрядчика или свободный текст. Пример из статьи: в назначении стоит условный счёт INV-042, и тот же номер находится в документах заявки REQ-017. Это предметная связь. Если совпали только подрядчик и сумма, заявку можно предложить как кандидата, но не выдавать за факт: одинаковые суммы бывают у регулярных услуг, авансов и этапных оплат. В раннем варианте запасной поиск сам выбирал «лучшего» кандидата. Сейчас автор показывал бы уровень уверенности, а спорные связи отправлял человеку.
Вторая ловушка менее очевидна. В группе компаний одна из баз 1С может не обновиться, и интерфейс покажет «оплачено 0». Сотрудник прочитает это как доказательство неоплаты, хотя на деле просто не хватает данных. Поэтому рядом с суммой нужно показывать полноту источника.
Когда связи появились, накопитель стал рабочим справочником: от подрядчика к заявке, договору, условиям, принятому объёму и платежам, а из БДДС (бюджета движения денежных средств) от объекта к виду работ, заявке и документу. По наблюдению автора, сотрудники ПТО раньше могли тратить на поиск договора или подтверждения оплаты 1–2 часа, а с готовой карточкой находили ответ за минуты. Он оговаривается, что секундомером это не мерил: это устные отзывы, а не измеренная экономия. Ещё один совет из статьи: сверяться с реестрами, которые ведут живые люди. Финансовый аналитик для проверки матчинга не нужен. Перенеси данные реестров оплат, работ и поставок в источник истины, и расхождения проявятся сами.
Договоры и документы на оплату: машина готовит, человек решает
Генератор договоров вырос из простого вопроса: если данные уже есть в заявке Bitrix24, зачем юрист каждый раз переносит их в шаблон руками? Сервис берёт сведения заявки, реквизиты и коммерческое предложение и заполняет Word-шаблон. На выходе получается не только .docx, но и лог: какое значение подставлено, откуда оно взято и что осталось проверить.
Принцип тот же, что в финансах: неизвестное нельзя незаметно превращать в уверенное. Нет даты окончания — ставится пометка. Сумма в КП не совпадает с суммой договора — показывается расхождение. Не хватает реквизитов — юрист видит это до согласования. Юридическую работу сервис не отменяет: условия и формулировки проверяет юрист, он же решает, согласовать проект или вернуть.
Автор аккуратно разделяет степени готовности. Генератор работает. Сводка его ошибок уже выводится на общий экран. Интеграция с сервисом задач подготовлена, но по умолчанию выключена. Отдельно упомянута база, которую автор назвал «косячники»: туда попадают инициаторы с повторяющимися ошибками в заявках Bitrix24, и в дальнейшем она служила основанием для депремирования.
С документами на оплату тоже не всё просто. В одной заявке бывают договор, допсоглашение, счёт, АВР, КС-2 и КС-3. Документ может лежать не в том поле, несколько файлов бывают склеены в один PDF, а один файл прикреплён дважды. Поэтому чтение устроено как процесс: получить вложения, убрать повторы, определить тип документа, извлечь факты. Модель превращает PDF и сканы в поля: суммы, условия аванса и удержаний, принятые объёмы, номера, реквизиты.
Фразе «ИИ прочитал договор» автор не доверяет. Модель может принять сумму акта за сумму договора или пропустить вторую часть склеенного PDF. Поэтому каждый результат должен вести к исходному файлу. Если существенные поля не извлечены, нельзя записать пустую карточку и считать заявку проверенной.
Связанные данные дают две проверки перед платежом. Первая: не платили ли за это уже? Совпавшая сумма или счёт — повод разобраться, а не обвинение в задвоении. Вторая: не выходит ли оплата за пределы договора или принятого объёма? Упрощённая формула из статьи:
остаток = сумма договора − удержание − бартер − фактически оплачено
Автор предупреждает про аванс: если он уже отражён платежом в 1С, второй раз его вычитать нельзя. Оплата без акта может оказаться договорным авансом, так что система показывает условие и риск, а решает человек. К карточке заявки можно подтянуть сведения о контрагенте из внешнего источника.
Люди на объекте: две цифры, которые нельзя складывать
Сначала автору казалось, что нужен один «учёт персонала». Потом выяснилось, что вопросов два.
HR нужно знать о своих сотрудниках: кто пришёл, во сколько ушёл, кто опоздал, кто подал заявку на отсутствие, какие задачи в работе. Для этого есть сервис с ботом и кабинетом: отметки, табель, график, заявки и панель HR.
Строительному блоку нужно другое: сколько человек конкретный подрядчик вывел сегодня на объект и на какие работы. Эти данные ведутся в рабочей таблице. Отдельный сервис разбирает её по объектам и подрядчикам, сравнивает с предыдущим заполненным днём и сигнализирует, если людей стало меньше. Спецтехника считается отдельно, иначе к людям прибавится автокран.
Главная мысль раздела: не складывать обе цифры в одно поле «на объекте работают N человек». У них разное происхождение, разная частота обновления и разные правила проверки. Общий экран когда-нибудь сможет поставить их рядом, но сначала пользователю нужно объяснить, кого считает каждая система.
Интеграция ERP системы: общий экран без второй копии данных
Когда сервисов стало несколько, возник соблазн завести ещё одну базу и копировать туда всё. Автор от этого отказался: пришлось бы поддерживать вторую версию финансовых правил, второй список ошибок договоров и второй расчёт численности. Факты остаются там, где возникают, а экран руководителя только читает их короткие снимки.
Сейчас экран показывает финансовую сводку и результаты генерации договоров. Учёт времени, задачи и другие операционные направления — следующий этап. Автор подчёркивает: заявка пока не проходит путь от подрядчика до банка без участия человека. Цель прежняя: заявка движется по понятным ролям, рядом лежат документы и проверки, ответственный видит готовую справку и решает. Чем больше автоматизации, тем важнее след: кто подтвердил, на каком основании и какие данные видел в тот момент.
Прорехи автор перечисляет сам. Главная — качество связей. Назначение платежа бывает пустым или неоднозначным, один счёт оплачивается частями, одинаковая сумма встречается много раз и не является дублем. Справочники объектов и подрядчиков не становятся чище от нового интерфейса.
Оценивать систему одной цифрой «сматчили X% платежей» он не советует: можно связать много строк и ошибиться в важных случаях. Лучше считать отдельно связи по однозначному номеру, связи по эвристике и то, что осталось на ручной разбор. Факт последующей оплаты доказывает только то, что платёж состоялся, а не то, что система правильно определила риск или договор. Для честной оценки нужен размеченный набор сложных случаев и проверка человеком. Часть находок подтверждалась устно, но превращать это в процент точности без протокола автор не хочет.
Его вывод для следующей итерации полезен всем, кто планирует внедрение ERP системы: раньше заняться общими справочниками объектов и контрагентов, статусом полноты источников и уверенностью в каждой связи. Именно эти скучные вещи решают, можно ли доверять красивому экрану.
Коротко
- Автор собрал ERP-контур для стройки из пяти сервисов поверх 1С и Bitrix24: финансы, договоры, учёт времени, численность на объектах и экран руководителя. Одной бесшовной системой это пока не стало.
- Смета, договор, акт и платёж — разные факты из разных источников. Сливать их в одну цифру опасно, система должна помнить происхождение каждого числа.
- Связи между платежами и документами нужно показывать с уровнем уверенности, а спорные отдавать человеку. Нули из необновлённой базы нельзя выдавать за отсутствие оплаты.
- ИИ полезен для извлечения полей из договоров и сканов, но каждый результат должен вести к исходному файлу, а решение остаётся за юристом или финансистом.
- Ценность системы — в возможности пройти от числа на экране до заявки, документа или платежа. Без этого пути получается ещё одна сводка, которую перепроверяют вручную.
Что я об этом думаю
Больше всего меня зацепила честность в оценке готовности. Автор всё время разделяет «работает», «выводится на экран», «подготовлено, но выключено» и «пилот». В большинстве рассказов про автоматизацию эти уровни слипаются в одно «мы внедрили», и потом никто не понимает, почему цифрам на дашборде никто не верит.
Вторая сильная мысль — отказ от второй копии данных. Соблазн собрать всё в одну базу ради красивого экрана понятен любому, кто автоматизирует процессы в своём бизнесе. Я тоже регулярно ловлю себя на этом желании. Схема «факт живёт там, где возник, а экран читает снимки» скучнее, но её проще поддерживать.
Чего мне не хватило — хотя бы примерной цены и сроков: сколько времени заняли пять продуктов и какой командой. Автор сознательно скрывает реальные данные, это понятно, но для того, кто сравнивает такой путь с покупкой готовой системы, это главный вопрос. И отдельно меня смутила база «косячников» для депремирования: как инструмент дисциплины она работает, но без разбора причин ошибок рискует наказывать людей за плохой шаблон заявки.
Материал пригодится тем, кто живёт между 1С и Bitrix24 и уже стал «интерфейсом между системами». Это хороший пример того, как начинать с одной боли и наращивать контур, не обещая руководителю кнопку «ИИ сделает всё».
Источник: Как я собирал ERP контур из 5 продуктов для строительной компании