Как составить техническое задание на видеонаблюдение для закупки: структура, параметры и нормы Узбекистана

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

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

Хорошее ТЗ можно проверить: каждое требование либо измеряется (мегапиксели, дни архива, метры ИК-подсветки), либо проверяется тестом при приёмке. Формулировки «высокое качество изображения» или «надёжное оборудование» бесполезны — их нельзя ни сравнить, ни принять.

Для объекта от десятка камер ТЗ удобно собирать из десяти разделов:

1. Объект и цель. Адрес, назначение здания, площадь, этажность, режим работы и то, чего добивается заказчик: контроль периметра, приёмки товара, касс, проходной.
2. Зоны и задача в каждой зоне. Обзор — видно, что происходит; различение — видны действия и предметы; идентификация — можно узнать лицо или прочитать номер. Чем выше задача, тем больше пикселей приходится на объект и тем ближе ставится камера.
3. Требования к камерам. Разрешение, объектив или угол обзора, ИК-подсветка, исполнение для улицы, аналитика.
4. Запись и архив. Режим записи (постоянная, по движению, по расписанию), глубина архива в днях, кодек.
5. Хранение и доступ. Где физически лежит архив, кто и с каких устройств его смотрит, как выдаются записи.
6. Сеть и питание. PoE, коммутаторы, резервное питание, выделенная сеть видеонаблюдения.
7. Интеграция. Со СКУД, охранной сигнализацией, уже работающей системой видеонаблюдения или платформой управления.
8. Требования к монтажу. Способ прокладки кабеля (лоток, гофра, короб), высоты установки, маркировка, работа на действующем объекте.
9. Документация и обучение. Исполнительные схемы, список оборудования с серийными номерами, учётные записи, инструкция для охраны.
10. Приёмка и гарантия. Перечень испытаний, гарантия на оборудование и на работы, порядок гарантийного обращения.

Разделы 2 и 4 сильнее всего влияют на бюджет: задача «идентификация» на каждом входе и архив на 90 дней вместо 30 меняют смету в разы. Поэтому их согласуют с владельцем объекта и службой безопасности до объявления закупки, а не после получения предложений.

Готовый шаблон ТЗ в формате DOCX с этой структурой — таблицей параметров, формулой расчёта архива и перечнем приёмочных испытаний — можно скачать на этой странице.

Параметр в ТЗ формулируется как минимальное значение или диапазон, а не как модель. Примеры формулировок:

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

Запас по каналам и потоку — тоже требование, а не пожелание. Регистратор, заполненный под завязку, нельзя расширить без замены, а камеры с высоким битрейтом на регистраторе со слабым входящим потоком теряют кадры. Пример: 32 камеры по 4 Мбит/с дают 128 Мбит/с; регистратор с входящим потоком 256 Мбит/с (такой поток у 32-канального Hikvision DS-7732NI-K4 по карточке каталога) держит двукратный запас, а при 8 Мбит/с на камеру работает уже на пределе. Питание по PoE через витую пару ограничено 100 метрами от коммутатора — дальние камеры в ТЗ лучше сразу описывать с оптикой или выносным коммутатором.

Глубину архива задают в днях при определённом режиме записи, а объём дисков участник рассчитывает сам. Формула для проверки предложений: объём (ТБ) = число камер × битрейт (Мбит/с) × 86 400 × дни / 8 / 1 000 000. Пример: 32 камеры 4 Мп с кодеком H.265 при постоянной записи и битрейте около 2 Мбит/с дают 64 Мбит/с — около 691 ГБ в сутки и около 20,7 ТБ за 30 дней. Битрейт 2 Мбит/с — допущение для типовой сцены; реальное значение зависит от настроек и движения в кадре. Поэтому в ТЗ надёжнее писать «архив не менее 30 суток при постоянной записи всех камер в основном потоке», а при приёмке проверять фактическую глубину. Срок 30 суток для обычного видеонаблюдения в этом примере — это не норма закона, а совет практиков; срок, установленный нормой, есть у отдельных объектов — например, архив не менее 6 месяцев для негосударственных образовательных организаций по ПКМ № 271 (подробнее — в разделе о нормах).

Место хранения — отдельное требование. Закон ЗРУ-547 «О персональных данных» относит к персональным данным информацию, относящуюся к определённому человеку или позволяющую его идентифицировать (ст. 4), а биометрическими считает данные об анатомических и физиологических особенностях (ст. 26). Статья 27-1 в редакции Закона ЗРУ-1125 от 26.03.2026 обязывает хранить на территории Узбекистана биометрические и генетические данные и данные абонентов операторов связи. Шаблоны лиц в терминалах СКУД и в системах распознавания лиц — биометрия, их база должна находиться в республике.

Для обычной видеозаписи прямого указания в статье 27-1 нет: прочие персональные данные закон разрешает хранить за рубежом при выполнении одного из условий — признанная адекватная защита в стране, стандартные договорные условия или международные стандарты у оператора. Это не норма закона, а совет практиков: мы рекомендуем консервативный вариант и формулируем его в ТЗ так: «архив хранится на оборудовании, установленном на объекте, или в центре обработки данных на территории Республики Узбекистан; облачный сервис используется для удалённого просмотра». Окончательную формулировку для своего объекта согласуйте с юристом.

Государственному заказчику — по общему правилу нельзя. Часть третья статьи 34 Закона ЗРУ-684 от 22.04.2021 «О государственных закупках» в редакции Закона ЗРУ-1005 от 27.11.2024 (действует с 01.03.2025) запрещает включать в описание закупки требования или ссылки на конкретный товарный знак, наименование, патент, конструкцию или модель, источник происхождения или производителя. Исключений два: закупки через электронный магазин и случаи, когда нет другого достаточно точного способа описать характеристики. Во втором случае в описание обязательно включаются слова «или аналог» — кроме случаев несовместимости товаров. Закон продолжают менять, поэтому редакцию проверяйте на дату объявления закупки.

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

Корпоративный заказчик вне государственных закупок свободен в выборе, но и ему нейтральное по бренду ТЗ выгодно: больше участников — честнее сравнение цен. Если ориентир на модель всё же нужен, рабочий приём — указать модель как пример и перечислить измеримые критерии эквивалентности: разрешение, угол обзора, дальность ИК, класс защиты, кодеки, стандарт PoE, функции аналитики, поддержку протокола ONVIF для подключения к регистратору. Аналог, который проходит по всем критериям, принимается; это легко проверить и трудно оспорить.

Требование «архив не менее 6 месяцев» для школ — самое затратное. Одна камера 4 Мп при 2 Мбит/с пишет около 21,6 ГБ в сутки и около 3,9 ТБ за 182 дня; 24 камеры при круглосуточной постоянной записи — около 94 ТБ. Запись по расписанию учебного дня и кодек H.265+ снижают объём, поэтому в ТЗ для школы режим записи прописывают явно, а не оставляют на усмотрение участника.

Раздел приёмки превращает ТЗ в чек-лист. Минимальный набор испытаний:

1. Каждая камера показывает изображение и пишет в архив; список камер в регистраторе совпадает со схемой и спецификацией.
2. Фактическая глубина архива соответствует ТЗ: проверяется самая старая запись после выхода системы на полный цикл или расчёт по фактическому потоку.
3. Ночное изображение проверено в темноте в каждой уличной зоне; в зонах идентификации лицо или номер различимы.
4. Время на камерах и регистраторе синхронизировано, метки времени в архиве корректны.
5. Заводские пароли заменены, учётные записи созданы по ролям, прошивки обновлены.
6. Удалённый доступ работает по ролям: руководитель, охрана и ИТ видят только назначенные камеры.
7. Резервное питание держит регистратор и коммутаторы при отключении сети.
8. Переданы исполнительные схемы, список оборудования с серийными номерами, учётные данные администратора и инструкция для охраны.

Так сдаём объекты и мы: исполнительные схемы, список оборудования с серийными номерами, сетевые адреса и учётные записи передаём заказчику под подпись.

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

1. Модель вместо требований: закупка сводится к одной позиции, а у государственного заказчика это противоречит статье 34 ЗРУ-684.
2. Нет задачи по зонам: участники предлагают одинаковые камеры на вход и в коридор, и лицо на входе потом не различить.
3. Архив указан в терабайтах, а не в днях: объём дисков ничего не говорит о глубине архива при конкретном битрейте.
4. Не указано, где лежит архив и кто к нему допущен: это всплывает при первом запросе записи.
5. Ссылки на российские СП в части пожарной автоматики вместо ШНК 2.04.09-2007.
6. Нет запаса по каналам, портам PoE и мощности: расширение через год требует замены оборудования.
7. Нет раздела приёмки: спор о выполнении требований решается на словах.

Пришлите ТЗ, спецификацию или рабочую документацию через страницу «Поставки и тендеры» или на sales@satsolutions.uz — подготовим КП со спецификацией и ведомостью работ по вашим требованиям; КП — в течение 24 часов.

• SAT Solutions — бренд ООО «SUPPLY AND TRANSPORTATION», ИНН 308603912. Ташкент, ул. Катта Дархон, 5; +998 97 862-66-99; sales@satsolutions.uz; Пн–Пт 9:00–18:00.
• Поставка оборудования и монтаж: видеонаблюдение, СКУД и турникеты, учёт рабочего времени, охранная и пожарная сигнализация, домофония, СКС и ЛВС, Wi-Fi, оптика, серверные. Монтаж ведёт собственный штат: 3 инженера и 15 монтажников.
• Документы: разрешение Национальной гвардии № 1554491 — монтаж, наладка и техобслуживание технических средств охраны; разрешение МЧС № 913518 от 23.07.2025 — монтаж, наладка и техобслуживание пожарной сигнализации и автоматического пожаротушения; оба — в уведомительном порядке по ПКМ № 88 от 25.02.2022.
• Гарантия 3 года на монтажные работы; на оборудование — гарантия производителя от 1 до 3 лет.
• Каталог satsolutions.uz — более 2 500 позиций; собственный склад в Ташкенте, ходовые позиции в наличии. Работаем с НДС, цены в сумах с НДС; электронные счета-фактуры (ЭСФ) выставляем через оператора электронного документооборота.