IT-системы для стройкомпаний: выбор

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

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

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

С чего начать: задачи компании и список требований

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

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

Отдельно записывают ограничения: сколько пользователей работает одновременно, какие объекты и юридические лица ведутся в системе, нужен ли удалённый доступ с площадки, требуется ли российское программное обеспечение из реестра Минцифры. Последнее обязательно, если компания участвует в закупках по 44-ФЗ или 223-ФЗ и заказчик выставляет такое требование к своим подрядчикам.

Когда список готов, его согласуют с финансовой службой, сметным отделом, производственным блоком и адвокатом. Адвокат проверяет не функции, а последствия: кому принадлежат данные, что будет при расторжении договора, как система подтверждает авторство и время изменений. Эти вопросы вынимают на поверхность те риски, которые иначе всплывают уже в суде.

Размер компании меняет подход. Небольшой подрядчик с двумя-тремя объектами чаще всего обходится облачным сервисом по подписке, где поставщик отвечает за хранение и резервирование. Крупная организация с несколькими юридическими лицами нуждается в единой базе, разграничении прав и собственном контуре безопасности. В обоих случаях закрепляют в письменном виде, кто администрирует систему, кто вправе выдавать доступы и кто отвечает за сохранность данных. Без такого распределения при утечке или потере базы виноватого ищут уже после ущерба.

Учёт: какие данные система хранит и как они работают как доказательство

Учётный контур строительной компании включает договоры, объекты, статьи затрат, выполнение по этапам, расчёты с контрагентами и первичные документы. Закон о бухгалтерском учёте (402-ФЗ) требует, чтобы факты хозяйственной жизни подтверждались первичными документами. Если документ электронный, он подписывается электронной подписью. Система учёта должна поэтому уметь не только создавать акт, но и сохранять подписанный файл вместе с данными о подписанте.

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

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

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

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

Сметы: как система работает с ценой и объёмами

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

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

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

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

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

Управление проектами и графиками: данные для споров о сроках

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

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

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

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

Интеграции и обмен с контрагентами

Большинство проблем IT-ландшафта возникает на стыках. Сметная программа выгружает данные в учётную, учётная передаёт документы в систему электронного документооборота, оператор ЭДО отправляет их контрагенту. Если на стыке теряется поле или меняется формат, итоговый документ отличается от исходного. Документ, который расходится с данными учёта, превращается в аргумент оппонента.

Проверяйте, какие форматы обмена поддерживает система. Для электронных универсальных документов и счетов-фактур существуют форматы, которые утверждает ФНС. Для актов по формам КС-2 и КС-3 операторы используют собственные форматы или сканы, поэтому заранее уточняйте у оператора и у контрагента, в каком виде документ будет подписан и как он сохранится.

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

Интеграция с банком, с ЕИС для закупок и с кадровой системой добавляет вопросы персональных данных. Закон о персональных данных (152-ФЗ) требует определить цели обработки и обеспечить защиту. Если в строительной системе хранятся паспортные данные работников субподрядчика, компания отвечает за их защиту. Включайте в договор с поставщиком условия о месте хранения данных и о доступе сотрудников поставщика.

Договор на внедрение и лицензию: условия, из-за которых спорят

Спор с поставщиком IT-системы почти всегда начинается с формулировок договора. «Внедрение системы» без перечня работ превращается в бесконечные доработки. Поэтому договор разделяют на части: лицензия или подписка, внедрение и настройка, обучение, сопровождение. Каждая часть получает отдельный порядок приёмки и отдельную цену.

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

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

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

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

Порядок выбора и ошибки, которые повторяются

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

Пилот проводят на реальных данных, а не на демонстрационных. В пилоте проверяют, как система создаёт акты, как связывает их со сметой, как передаёт документы оператору ЭДО, как восстанавливает данные после сбоя. Результаты записывают в протокол, подписанный обеими сторонами. Этот протокол потом служит доказательством того, какие функции работали на момент принятия решения.

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

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

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

Основной канал связи с адвокатом — электронная почта sporystroitelnye@gmail.com