Закупка АСУ по 44-ФЗ: что заложить в ТЗ, чтобы получить сопоставимые предложения

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

Ниже - пять пунктов, из-за отсутствия которых чаще всего расходятся предложения на закупках систем автоматизации и мониторинга в госсекторе, и как их закрыть в тексте ТЗ. Фактура - два проекта, выполненных Энтренд по 44-ФЗ: нижний уровень единой системы мониторинга инженерных систем на 53 объектах Федеральной таможенной службы и система мониторинга энергоресурсов на 21 объекте государственного заказчика, реализованная в два контракта подряд.

Граница между уровнями системы - формулируется явно, а не подразумевается

Коротко: если в ТЗ не зафиксировано, где заканчивается зона ответственности исполнителя и начинается зона заказчика, участники закупки посчитают разный объём работ по одному и тому же документу.

Система мониторинга или телемеханики почти всегда состоит из двух уровней: нижнего (контроллеры, шкафы автоматики, КИПиА, сбор телесигналов на объекте) и верхнего (программная платформа, аналитика, отчётность, интеграция с системами вышестоящего уровня). На проекте ЕСУМИС для ФТС России границу задавал сам контракт: исполнитель выполнял нижний уровень - проектирование, поставку отечественного оборудования и шкафов автоматики, монтаж и пуск, включая подсистему телемеханики и дистанционного управления, - а программная часть верхнего уровня оставалась зоной ответственности заказчика. Это разграничение было зафиксировано в техническом задании до объявления закупки, и каждый участник считал предложение по одному и тому же объёму.

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

Что фиксирует ТЗ	Зачем
Перечень подсистем нижнего уровня и их состав по каждой (электроснабжение, ОВиК, противопожарные системы)	Исключает ситуацию, когда часть подсистем «потерялась» между исполнителем и заказчиком
Точка передачи данных на верхний уровень - протокол, формат, точка интеграции	Даёт участникам закупки одинаковое понимание объёма пусконаладочных работ
Кто отвечает за приём мониторинговых сигналов от смежных систем (пожарная, охранная) - без управления ими	Разграничивает мониторинг и управление, которые в госзакупках часто путают в один пункт

Реестровая принадлежность - конкретный реестр и дата актуальности, а не слово «отечественное»

Коротко: требование «оборудование должно быть отечественным» без ссылки на конкретный реестр и без указания момента проверки позволяет участникам закупки трактовать его по-разному и приводит к спорам уже после заключения контракта.

Для программно-аппаратной части закупок в госсекторе действуют два разных реестра: аппаратное оборудование проверяется по реестру Минпромторга (радиоэлектронная продукция российского происхождения), программное обеспечение - по реестру российского ПО Минцифры. Это разные ведомственные списки с разными критериями включения, и требование «оборудование из реестра» без уточнения, какого именно, оставляет участнику закупки пространство для подмены.

На проекте мониторинга энергоресурсов для 21 объекта госзаказчика оба реестра были задействованы одновременно и по разным компонентам: контроллер на пограничном уровне работал на защищённой операционной системе Kaspersky OS, а платформа приёма и обработки данных Inspark IoT - продукт из реестра российского ПО Минцифры. Смешение этих двух требований в одну строку ТЗ - типичная причина, по которой участник закупки предлагает оборудование, формально «отечественное», но не соответствующее нужному реестру для нужного класса продукции.

Отдельный пункт - момент проверки. Реестровые записи меняются: часть позиций исключается, часть добавляется, модели обновляются. На проекте с ФТС часть проектных решений, изначально предполагавших импортные компоненты, пересматривалась по ходу исполнения контракта по мере включения нужных позиций в реестр. ТЗ, которое требует подтверждения реестровой принадлежности «на дату закупки» без учёта того, что контракт может растянуться на месяцы, создаёт разрыв между тем, что участник предложил на старте, и тем, что физически можно поставить на момент монтажа.

Тиражируемость архитектуры - обязательное требование для контрактов на несколько объектов

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

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

Ответ на этот риск в обоих случаях был одинаковым - модульная архитектура, где типовой состав шкафа и логика подключения не зависят от конкретной модели компонента. На нижнем уровне ЕСУМИС состав шкафов и КИПиА адаптировался под каждый объект без пересмотра общей архитектуры решения. На мониторинге энергоресурсов архитектура, отработанная на первых 11 объектах, тиражировалась на следующие 10 без переработки - изменилась только спецификация конкретных моделей, сама архитектура осталась прежней, и цикл проектирования на втором этапе сократился за счёт типизации.

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

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

Достоверность измерительных трактов - отдельное требование, если система про учёт

Коротко: если предмет закупки включает учёт энергоресурсов, ТЗ обязано требовать проверку узлов учёта до включения в контур мониторинга, а не только монтаж и пусконаладку самого контроллера - иначе система с первого дня показывает недостоверные данные.

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

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

Работа на объекте с ограниченным доступом - процедурная часть ТЗ, а не приложение

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

На объектах ФТС России работы велись на режимной территории с соблюдением внутренних регламентов заказчика по работе с информацией ограниченного доступа: персонал, выполнявший монтаж, проходил инструктаж и был оформлен по требованиям заказчика, а каждый этап строительно-монтажных работ согласовывался со службой эксплуатации и режимной службой отдельно. Эти процедуры занимают время, которое либо заложено в график исполнения контракта заранее, либо становится источником срыва сроков, за который стороны потом спорят, кто виноват.

Если ТЗ не описывает процедуру допуска и её ориентировочные сроки, участник закупки посчитает график исходя из «обычного» объекта без режимных ограничений - и предложенный им срок объективно недостижим для конкретной площадки.

Что заложить в ТЗ

• Явное разграничение уровней системы (нижний / верхний) и точку интеграции между ними - протокол, формат данных, кто отвечает за приём мониторинговых сигналов от смежных подсистем.
• Требование к реестровой принадлежности по каждому классу продукции отдельно: реестр Минпромторга для аппаратной части, реестр российского ПО Минцифры для программной, с указанием момента проверки актуальности записи.
• Порядок действий при исключении заложенной в спецификацию позиции из реестра в ходе исполнения длинного контракта - кто несёт затраты на пересмотр спецификации.
• Требование подтвердить тиражируемость архитектуры для закупок на несколько объектов или контрактов подряд - модульность состава шкафов и независимость архитектуры от конкретной модели компонента.
• Отдельный этап проверки и, при необходимости, поверки измерительных трактов до включения узлов учёта в контур мониторинга, если предмет закупки связан с учётом ресурсов.
• Процедура допуска персонала и согласования графика работ на режимных объектах или объектах с информацией ограниченного доступа - как часть основного текста ТЗ, а не отдельное приложение, согласуемое после заключения контракта.
• Критерии приёмки, сформулированные так, чтобы их можно было проверить объективно: состав протоколов испытаний, перечень тестовых сигналов, порядок сдачи программе, согласованной с заказчиком.

Частые вопросы

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

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

Нужно ли в ТЗ указывать конкретных производителей оборудования? Указание конкретного производителя вместо характеристик и требования к реестровой принадлежности сужает конкуренцию и обычно противоречит духу закупочной процедуры. Формулировка через функциональные характеристики и обязательную реестровую принадлежность даёт то же самое ограничение по составу, но оставляет закупку конкурентной.

Как оценить, потянет ли участник закупки тиражирование архитектуры на второй этап многолетнего контракта? Запросить референсы именно по многообъектным или многоэтапным госконтрактам, а не по единичным внедрениям. Тиражирование архитектуры без переработки - отдельная компетенция, отличная от способности спроектировать решение для одного объекта.

Кто должен инициировать проверку узлов учёта - заказчик до объявления закупки или исполнитель после заключения контракта? Практически - исполнитель, потому что у заказчика обычно нет ресурса на полную инвентаризацию состояния узлов учёта по всем объектам заранее. Но эта работа и её результат (согласование с метрологической службой заказчика) должны быть отдельным этапом в ТЗ с собственным сроком и приёмкой, а не подразумеваемой частью пусконаладки.

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

Источники

• ЕСУМИС для Федеральной таможенной службы - кейс: нижний уровень системы мониторинга на 53 объектах, госконтракт по 44-ФЗ, отечественное оборудование, режимная территория.
• Мониторинг энергоресурсов на 21 объекте государственного заказчика - кейс: два контракта подряд, тиражирование архитектуры, защищённый стек Kaspersky OS и Inspark IoT, проверка достоверности узлов учёта.
• Импортозамещение АСУ ТП по 187-ФЗ: чек-лист готовности объекта КИИ - смежная тема: дедлайны и реестровые требования для объектов критической информационной инфраструктуры.
• Помощь с ТЗ - страница услуги: как устроен процесс подготовки технического задания до объявления тендера.

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