Задание на проектирование — важнейший документ на который все плюют

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

Подрядчику некогда — огромная конкуренция заставляет делать объекты «на потоке». Заказчики как правило не обладают компетенциями в сфере видео. Механизм независимого аудита / консалтинга в РФ не развит, да и о чем говорить — он доступен лишь для крупных систем с большим бюджетом, когда третья сторона действительно не лишние расходы — а возможность выбрать оптимальные решения без ухудшения функционала и без завышения стоимости. Что же остается делать простым заказчикам? Требовать составления грамотного ТЗ — задания на проектирование! А лучше — составить ТЗ самостоятельно.

---

Содержание:

1) Текущее положение дел с ТЗ
2) Зачем ТЗ (задание на проектирование) — Заказчику?
3) Правовой статус задания на проектирование для Подрядчика
4) Ошибки в составлении задания на проектирование
5) Какие требования лучше включить в ТЗ?
6) Оформление задания на проектирование — российские требования (ГОСТ Р 57839-2017)
7) Опыт других стран: рекомендации по составлению эксплуатационных требований к системе видеонаблюдения
8) Выводы

---

Кому адресован этот блог и почему моему мнению можно доверять.

Мои контакты — пишите по любым интересующим вопросам, в том числе предложения о сотрудничестве.

---

1) Текущее положение дел с ТЗ

Видеонаблюдение может быть очень эффективным вложением средств, особенно для среднего и крупного бизнеса. Но для того, чтобы добиться той самой эффективности — нужно приложить усилия. А пока и заказчики, и подрядчики предпочитают «не заморачиваться». Подрядчик выбирается «сердцем», а чаще «кошельком». При этом подрядчик как правило заинтересован сделать заказ как можно быстрее, с минимальной себестоимостью и максимальной прибылью. Нет времени вникать в задачу заказчика: как правило используются наработанные типовые решения (что сокращает сроки проектирования, монтажа и главное — пусконаладки), с типовым и понятным оборудованием и софтом, которые к тому же можно закупить для заказчика с хорошими скидками от розничной цены. В итоге система установлена и даже работает. Но про то, ради чего все затевалась и были потрачены деньги — все (и заказчик и подрядчик) — благополучно забыли.

В итоге таких совместных действий заказчика и подрядчика система видеонаблюдения будет установлена на объекте и даже будет работать. Подрядчик, довольный быстрыми (хоть и не большими) деньгами пойдет «окучивать» следующий объект, а заказчик будет доволен своим прекрасным умением оптимизировать бюджет и экономить кровные деньги. Описанная мною идиллия будет продолжаться вплоть до серьезного инцидента (а это может случиться и через пол года, и через год, и через пять — а может и вовсе не случиться). И вот тогда наступает момент истины — закрывает ли система видеонаблюдения реальную потребность заказчика или все ее назначение сводилось к проставлению галочки в отчете или голове заказчика что уже теперь «все под контролем»:

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

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

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

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

Признаем и тот факт, что проектирование не всегда доступно заказчику. Но это вовсе не означает, что систему можно покупать и устанавливать без предварительного планирования.

Техническое задание (ТЗ) в случае отсутствия проекта — это основной документ по которому будет проведена процедура выбора подрядчика, закупки оборудования и приемки системы в эксплуатацию.

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

И в том и в другом случае задание на проектирование / ТЗ не выполняют свою роль важного этапа создания системы видеонаблюдения и вместо исходных данных для проектирования / планирования превращается в «to-do list» от заказчика — прикрути мне такие камеры к такой стене. Ответственность в этом случае полностью ложится на плечи заказчика, ведь от подрядчика не требуется принимать никаких решений — только выполнить то, что желает заказчик. «Хотели эту камеру в этом месте — ну так вот она, получите и распишитесь. Вы не можете по этой камере идентифицировать незнакомого человека или прочесть регистрационный номер автомобиля? Ну а я то тут при чем?»

2) Зачем ТЗ (задание на проектирование) — Заказчику?

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

Если вы все таки приняли решение внедрить видеонаблюдение в свой бизнес то к дальнейшему планированию нужно подойти ответственно, погружаясь в детали, не делегирую полностью задачу подрядчику. Речь конечно не идет о том, что вы должны понимать как все это работает, принципы формирования изображения на камере или проштудировать стек TCP/IP. Это было бы абсурдно — зачем тогда нужен подрядчик? Но вот сформулировать задачи внедрения и цели наблюдения кроме вас никто не сможет — ведь это именно ваш бизнес и видеонаблюдение — один из инструментов в ваших руках. Вы должны понять как будете его использовать и какие для этого потребуются ресурсы. Оборудование — лишь сердцевина тех ресурсов, которые необходимы для создания, поддержания в рабочем состоянии и эффективного использования системы видеонаблюдения. Это тоже нужно четко для себя осознать и принять. Либо отказаться от внедрения — возможно видеонаблюдение для вас — не лучший вариант решения задачи. И я не вижу в этом ничего страшного — хуже когда CCTV начинают считать волшебной пилюлей от всех проблем на объекте — это далеко не так.

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

3) Правовой статус задания на проектирование для Подрядчика

Надеюсь что в важности ТЗ для заказчика я вас смог убедить. Но какое отношение это имеет к подрядчику? Стоит ли разбираться в этом вопросе — или это полностью задача заказчика?

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

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

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

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

Важно понимать разницу между заданием на проектирование и техническим заданием (ТЗ). Задание на проектирование является юридически значимым термином. Оно упоминается во многих нормативно-правовых документах:

Термина техническое задание (ТЗ) в законодательстве РФ не существует. Дело в том, что законодательство не предполагает случая создания инженерной системы здания «хоз. способом» без этапа проектирования. Как же быть, если все таки проектирования как такового не будет, а подстраховать себя хочется?

Я бы все же рекомендовал прописать в договоре пункт о проектировании и создании рабочей документации. Оставлять объект совсем без документации после монтажа — это крайне не дальновидно: обслуживать, ремонтировать, модернизировать и расширять (масштабировать) такую систему будет проблематично. И чем больше с момента монтажа будет проходить времени — тем сложнее в плоть до полной невозможности модернизировать установленную систему с сохранением проложенных кабельных трасс (прецеденты имеются).

Содержание рабочей документации практически полностью определяется заданием на проектирование. И совсем не обязательно выпускать полноценную рабочую документацию если ваш бюджет этого не потянет. Пусть будет минимальный набор листов согласно ГОСТ Р 21.1101-2013 :

1. Титульный лист
2. Общие указания
3. Структурная схема
4. Схема расположения оборудования и прокладки кабельных трасс
5. Ссылочные документы (стандарты)
6. Прилагаемый документы: Спецификация оборудования, изделий и материалов

Если же даже такая «рабочка» вам не по карману — т.н. «ТЗ» можно выпустить в статусе приложения к договору. Т.е. его статус не будет отличаться от статуса договора по Гражданскому кодексу.

Вот некоторые выдержки из «нормативки»:

Гражданский кодекс РФ (ч.2) от 26.01.1996 № 14-ФЗ

Статья 759 Исходные данные для выполнения проектных и изыскательских работ

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

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

Постановление Правительства РФ от 16 февраля 2008 г. № 87

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

Разделы 6, 11, 5 и 9 проектной документации, требования к содержанию которых устанавливаются соответственно пунктами 23, 27(1) — 31, 38 и 42 настоящего Положения, разрабатываются в полном объеме для объектов капитального строительства, финансируемых полностью или частично за счет средств соответствующих бюджетов. Во всех остальных случаях необходимость и объем разработки указанных разделов определяются заказчиком и указываются в задании на проектирование.

Градостроительный кодекс РФ от 29.12.2004 № 190-ФЗ

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

Руководящий документ РД 25.952-90 «Системы автоматические пожаротушения, пожарной, охранной и охранно-пожарной сигнализации. Порядок разработки задания на проектирование»

1. Порядок разработки, согласования и утверждения задания на проектирование
1.1. Задание на проектирование является документом для разработки проектно-сметной документации.
1.2. Задание на проектирование составляет организация-заказчик с привлечением организации-разработчика.
1.3. Задание на проектирование согласовывается руководством организации-разработчика и утверждается руководством организации-заказчика.
1.5. Подписи должностных лиц, согласующих и утверждающих задание на проектирование, должны быть заверены печатями.

СНиП 11-01-95 Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений

 

2.7. Основным документом, регулирующим правовые и финансовые отношения, взаимные обязательства и ответственность сторон, является договор (контракт), заключаемый заказчиком с привлекаемыми им для разработки проектной документации проектными, проектно-строительными организациями, другими юридическими и физическими лицами. Неотъемлемой частью договора (контракта) должно быть задание на проектирование. Рекомендуемый состав и содержание задания на проектирование для объектов производственного назначения приведены в приложении А , а жилищно-гражданского назначения — в приложении Б.

ГОСТ Р 57839-2017 Производственные услуги. Системы безопасности технические. Задание на проектирование. Общие требования

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

4.1 Задание на проектирование системы является обязательным документом, необходимым для последующей разработки проектной документации системы согласно требованиям ГрК РФ (часть 11 статьи 48).

4.3 Задание на проектирование является основным документом заказчика, определяющим требования и порядок создания (строительства, реконструкции или капитального ремонта; далее — создания) системы, а также требования к составу, содержанию и порядку разработки проектной и/или рабочей документации.

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

5.2 Заказчик вправе самостоятельно разработать задание, либо поручить разработку задания проектировщику, либо привлечь к разработке задания третью сторону.

5.3 В случаях, если техническая система безопасности должна быть спроектирована для объекта, относящегося к перечню, указанному в статье 48.1 ГрК РФ, или функциональные требования к этой системе регламентированы принятыми техническими регламентами, привлекаемое для разработки задания лицо должно обладать допуском СРО к выполнению соответствующих проектных работ согласно требованиям ГрК РФ (часть 4 статьи 48), включая в необходимых случаях требования Постановления Правительства РФ от 24 марта 2011 г. N 207.

5.4 Лицо, привлекаемое для разработки задания на проектирование, несет ответственность перед заказчиком в соответствии с условиями договора и ГК РФ.

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

5.11 Проектировщик согласовывает задание при принятии его к исполнению, но не позже даты вступления в силу договора на проектирование. Не допускается согласование задания до его утверждения.

Согласование задания разрешается оформлять отдельным документом (письмом). В этом случае под грифом «Согласовано» делают ссылку на этот документ.

5.12 В случае если при согласовании задания на проектирование или в процессе проектирования проектировщик обнаружит в этом документе положения, применительно к защищаемому объекту противоречащие положениям принятых технических регламентов, или выяснит необходимость разработки СТУ (специальных технических условий), он обязан мотивированно сообщить об этом заказчику.

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

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

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

4) Ошибки в составлении задания на проектирование

 

Теперь, когда необходимость создания задания на проектирование / ТЗ не вызывает сомнений, давайте для начала разберемся с типовыми ошибками, для того чтобы никогда их не совершать.

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

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

Если вы заказчик — то вам нужна «правильная» картинка с камеры. А где она будет установлена — вопрос совершенно не важный. Лишь бы были соблюдены требования по безопасности (ПУЭ), защите от внешних воздействий окружающей среды и злоумышленников, а также требования к удобству технического обслуживания и, возможно, эстетике.

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

 

 

 

 

 

 

Посмотреть эту публикацию в Instagram

 

 

 

 

 

 

 

 

 

 

Ошибки проектирования

Публикация от Evgeniy Ozerov (@eozerov.ru) 18 Июл 2016 в 11:54 PDT

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

Необходимо «отделить мух от котлет» — требования от пути их реализации. В ТЗ нужно прописать именно требования, а как их достигнуть — это уже компетенция подрядчика, а никак не заказчика.

На это вы можете мне возразить — а как же быть, если у заказчика уже есть «любимое» оборудование, установленное на многих объектах? Разводить зоопарк? Конечно нет, на этот случай в задании на проектирование / техническом задании можно составить т.н. «вендор-лист» со списком разрешенных к использованию при проектировании / планировании марок либо даже конкретных моделей. При этом необходимо оставить возможность подрядчику мотивировано отказаться от использования «навязанных» моделей, если их применение не позволяет выполнить задачи видеонаблюдения в конкретной зоне.

И уж совсем детская ошибка — описывать «голый» функционал системы при отсутствии сформулированных задач и целей наблюдения. Почти всегда такие требования не несут никакой практической пользы для исполнителя (а ТЗ предназначается именно ему), повторяя стандартные формулировки, скопированные из интернета. Как правило таким «требованиям» удовлетворяют вообще все системы, представленные на рынке. А значит описывать это в задании на проектирование конкретного объекта конкретного заказчика — не имеет смысла; ведь нам нужно разобраться в специфике объекта, а не в типовом функционале любой системы видеонаблюдения.

5) Какие требования лучше включить в ТЗ?

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

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

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

1. Необходимо доказать факт того, что покупатель взял товар с витрины и не вернул на место (а например спрятал в одежде флакон духов)
2. Необходимо доказать факт того, что покупатель не оплатил взятый товар на кассе.
3. Необходимо сделать качественный фото-робот покупателя, достаточный для идентификации.
4. Биометрические данные покупателя должны быть собраны в базе системы видеонаблюдения. Видеоаналитический модуль системы должен анализировать лица входящих в магазины сети покупателей и сигнализировать охране при совпадении лица входящего покупателя с лицом, внесенным в «черный список».

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

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

Чем крупнее система, тем она, увы, менее надежна. И тем большие требования к надежности отдельных элементов системы нужно предъявлять, чтобы система была достаточно надежной. Существуют объективные параметры надежности как на отдельные компоненты системы (камеры видеонаблюдения, сервера, коммутаторы, рабочие станции и т.п.), так и на систему в целом. Подробную статью о том как выбрать и как рассчитать вероятностный параметр — коэффициент готовности — можно прочитать в моем блоге.

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

Существует некий оптимальный показатель надежности (коэффициента готовности), при котором общая сумма затрат на систему видеонаблюдения и потерь от неработоспособности системы за время ее эксплуатации будет минимальна. И именно данное значение следует принять в задании на проектирование (тут к сожалению без проектирования уже не обойтись — слишком сложно учесть все нюансы «на салфетке)».

Например, 1 день простоя системы — 50 000 руб потерь. В год мы готовы мириться с 5 днями неработоспособности системы — 5*50 000 = 250 000 руб. Предполагаемое время эксплуатации — 7 лет. Общие потери из-за неработоспособности системы — 7*250 000 = 1 750 000 руб. Коэффициент готовности = (365 дней в году — 5 дней простоя в году) / 365 = 0,9863. Если бы мы добились Кг=(365-4) / 365 = 0,9890 — то с одной стороны система бы «заработала» дополнительные 50 000 руб * 1 день в году * 7 лет = 350 000 руб. Но с другой стороны, сама бы стоила на X руб больше. И далее простой критерий — что больше — X дополнительных денег на систему или 350 000 руб заработанных более надежной системой денег.

Ещё одним аспектом, важным для крупных систем и не нужным для малых и средних — является возможность выбранное техническое решение масштабировать и стоимость этого масштабирования. Когда мы строим описанную выше систему отслеживания покупателей из «черного списка» для одного магазина — это одна история и выбор возможных вариантов реализации довольно широк и мы можем выбирать по разным критериям, в том числе по минимальной цене создания системы. Но когда нам требуется после первого пилотного проекта распространить данное решение на большую сеть объектов (в данном случае — сеть парфюмерных магазинов) — то вариантов реализации остается не так и много и цена уже не является решающим фактором — главное чтобы работало с заданной надежностью.

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

Видеонаблюдние имеет человек-машинный интерфейс. Необходимо детально продумать роль оператора (человека) в системе и проанализировать требуемые от оператора реакции на события в системе. Какую информацию должен получить оператор от системы видеонаблюдения? Как должен при этом действовать? Как можно ему помочь, увеличить его эффективность, автоматизировать рутинные действия? От эффективности человек-машинного интерфейса зависит эффективность решения той задачи, ради которой мы и внедряли систему видеонаблюдения.

Очень часто система видеонаблюдения используется для верификации (подтверждения) событий от других систем: системы контроля и управления доступом (СКУД), охранной и пожарной сигнализации и др. Для охранных систем систем — это и интеграция с периметральными системами охранной сигнализации, когда при сигнале о проникновении на объект мы, прежде чем высылать группу захвата, верифицируем инцидент по системе видеонаблюдения. Другой пример — связка видеонаблюдения и СКУД на проходной, когда при считывании карты доступа на мониторе охранника появляется «живое» видео с привязанной к данному контроллеру камеры и «карточка» пользователя СКУД с фотографией, что позволяет охраннику проверить правомерность пользования данной картой конкретного посетителя (не была ли карта сотрудника передана лицу, не имеющему доступ на объект).

Более подробно тему интеграции видеонаблюдения и других слаботочных и IT смистем я рассматривал в статье Видеонаблюдение как часть интегрированной системы безопасности.

Заказчик может быть заинтересован использовать в проекте уже проложенные коммуникации или закупленное оборудование. Это нужно обязательно указать в задании на проектирование. Например, если заказчик в прошлом вложил свои деньги в систему электрических и слаботочных лотков — то конечно имеет смысл прокладывать кабельные трассы с максимальным использованием этих лотков. Но подрядчик может просто не знать об их существовании при планировании системы и расчете коммерческого предложения.

Общая стоимость владения системой вовсе не равнозначна цене ее создания. Расходы на содержание системы, плановый и внеплановый ремонт, сотрудников, занятых эксплуатацией системы — могут значительно превосходить первоначальные вложения, о чем хорошо бы помнить при планировании системы.

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

Зачем нужен проект на систему видеонаблюдения и какие виду документации существуют мы подробно разбирали в статье Этапы создания системы CCTV и виды документации на каждом этапе. Стоимость создания проектной / рабочей документации зависит от требуемых на ее создание человеко-часов проектировщика. Чем более проработаны и детализированы проектные решения — тем дольше требуется проектировать и дороже итоговая документация. Требования к содержанию проектной документации весьма скромны и представлены в Постановление Правительства РФ от 16.02.2008 N 87, к содержанию рабочей документации их по сути нет (в ГОСТ Р 21.1101-2013 Система проектной документации для строительства. Основные требования к проектной и рабочей документации есть только требования к оформлению, но не к содержанию конкретных разделов). Поэтому на сколько подробный проект вы получите после этапа эскизного проектирования зависит, в первую очередь, от того какие требования к содержанию документации вы пропишите в задании на проектирование. Желательно подробно перечислить обязательные к выполнению листы проектной / рабочей документации.

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

В задании на проектирование очень желательно прописать весь список применяемой при проектировании нормативных документов. Это связано с техническим регулированием в РФ: обязательными являются только технические регламенты. А ГОСТы и своды правил имеют статус добровольного применения. Если их прописать в задании на проектировании — для проектировщика они становятся обязательными к исполнению.

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

В России, к сожалению, нет рекомендаций по разработке данных методик. Но можно воспользоваться международным опытом использования тестовых целей Rotakin и тестовых 9 лиц.

6) Оформление задания на проектирование — российские требования (ГОСТ Р 57839-2017)

С июня 2018 года вступил в силу ГОСТ Р 57839-2017 «Производственные услуги. Системы безопасности технические. Задание на проектирование. Общие требования». Это первый российский ГОСТ, описывающий специфику создания задания на проектирование технических систем безопасности. Некоторые замечания к данному ГОСТу я сформулировал в статье Техническое задание — миссия невыполнима?

Подход к составлению задания на проектирование, сформулированный в ГОСТ Р 57839-2017 — совершенно типичен для российских нормативных документов в целом. Основная идея наших стандартов — дать чёткие подробные указания что нужно сделать проектировщику.

Сложно себе представить заказчика, взявшего в руки ГОСТ Р 57839-2017 и полностью самостоятельно по данному ГОСТу выполнившего задание на проектирование. Это совершенно не вероятно. Во-первых — очень много разделов, к каждому довольно подробные требования по содержанию. Чтобы качественно составить ТЗ по данному ГОСТу — нужно потратить не один день.

Во-вторых (что стандартно для нашей «нормативки») — огромное число нормативных ссылок, каждая из которых содержит не меньшее число нормативных ссылок. Для самых въедливых читателей ГОСТа скачки по этим «дополнительным» ссылкам-материалам не закончится никогда — их можно читать «до посинения». И это при том, что по-настоящему полезной и применимой информации в каждой такой ссылке будет «кот наплакал». Это совершенно отбивает желание изучить стандарт досконально.

В третьих — стандарт содержит требования «как должно быть«, но ничего не говорит о том «как к этому прийти«. Методология составления задания на проектирование / ТЗ отсутствует как класс.

Если сравнивать со многими другими ГОСТами / сводами правил — ГОСТ Р 57839-2017 сделан качественно и со знанием дела. Но сам подход, заложенный в ГОСТ Р 57839-2017 мне кажется не продуманным. Судите сами. В ГОСТе четко прописано кто может составлять задание на проектирование:

• заказчик самостоятельно
• проектировщик
• третья сторона

Как мы уже выяснили — создать ТЗ самостоятельно среднестатистический заказчик не сможет. Нанять независимого эксперта — идеальный, но совершенно фантастический вариант, доступный только очень обеспеченным клиентам. Остается проектировщик. При этом ему (ну почти наверняка) за эту на самом деле серьезную, глубокую и тяжелую работу ничего не заплатят (заказчик не может понять за что платить проектировщику при выпуске документации — какие то бумажки — не то что задание на проектирование, которое уж совсем не вписывается в представление заказчика о бережливости и экономности). 1-2-3 дня, а то и неделя — «коту под хвост». Конечно проектировщик не заинтересован глубоко разбираться в проблемах заказчика. А вот «пропихнуть» нужное оборудование к которому уже привык, есть хорошие скидки от розницы или типовые решения — очень даже заинтересован. Вот только это может противоречить интересам заказчика.

Что же делать? На самом деле не все так плохо. Как я уже говорил — техническое регулирование РФ разделяет требования и способы их исполнения. 123-ФЗ, 384-ФЗ — обязательны для исполнения, а вот ГОСТ Р 57839-2017 — нет.

ГОСТ Р 57839-2017 может стать «условно» обязательным, только если попадет в перечень документов, применение которых на добровольной основе обеспечивает соблюдение требований одного из Тех. регламентов. Но пока это не произошло — ГОСТ сугубо добровольный, что, на мой взгляд, хорошо.

Это означает что мы можем применять его целиком на добровольной основе либо использовать как справочное пособие при составлении собственного ТЗ для удобства.

Все разделы задания на проектирование в ГОСТ Р 57839-2017 разделены на две части: обязательную и опциональную.

Обязательны следующие разделы / подразделы:

• Общие сведения
• Назначение системы и общие требования к проектированию
• Исходные данные для проектирования
• Нормативные требования к проектированию
• Технические требования к проектируемой системе
• Требования к сметной документации
• Требования к документации, подлежащей разработке и передаваемой заказчику по результатам проектирования

Опционально в задание на проектирование / ТЗ может содержать разделы / подразделы:

Технические требования к проектируемой системе:

• Требования к архитектуре и топологии системы
• Требования к системе по сопряжению с другими системами и оборудо­ванием
• Требования к применяемому оборудованию
• Требования к применяемому оборудованию ВТ и программному обеспечению
• Конструктивные и эргономические требования
• Требования по размещению оборудования и прокладке линий комму­никации
• Требования к электропитанию
• Требования электромагнитной совместимости
• Требования к защите от внешних воздействий
• Требования надежности
• Требования к сохранности информации и защите информации от НСД
• Требования безопасности
• Требования стандартизации и унификации

Требования экономической эффективности

Требования к монтажу и организации строительства

• Сведения об условиях строительства
• Требования к СМР
• Требования к маркировке
• Требования к испытаниям при ПНР и на этапе опытной эксплуатации, комплексного опробования и ввода в эксплуатацию

Требования к эксплуатации, обслуживанию и ремонту

• Общие требования по эксплуатации
• Требования к способам технического обслуживания
• Требования к эксплуатационным показателям, определяемым в про­цессе проектирования

Требования к выводу из эксплуатации, демонтажу и утилизации

Требования к патентной чистоте и защите авторских прав

В целом содержание ТЗ по ГОСТ Р 57839-2017 перекликается со многими приведенными мною выше рекомендациями.

7) Опыт других стран: рекомендации по составлению эксплуатационных требований

Принципиальное отличие европейских рекомендаций — наличие методологии составления эксплуатационных требований. Это позволяет использовать документ не только профессионалам (как в случае с отечественным ГОСТом), но и непосредственно самим заказчикам. Что снимает основную проблему российского подхода — конфликт интересов.

При использовании британского CCTV OPERATIONAL REQUIPMENT MANUAL 2009 мы должны пройти 4 этапа: определить проблему / задачу, которую необходимо решить и подходящий для этого инструмент. Это не обязательно будет видеонаблюдение. Если все же мы приняли решение использовать именно видеонаблюдение — то на втором этапе необходимо разобраться с целями наблюдения (т.е. что мы хотим видеть и почему мы это хотим видеть?). Только после этих двух этапов (а не как у нас — вместо 😉 ) — на третьем этапе идет формирование требований к отдельным элементам системы видеонаблюдения. Последний этап — сдача системы в эксплуатацию, на котором мы проверяем готовую к работе систему на способность решить сформулированные на первых двух этапах задачи.

Итак — вы решили что возможно вам нужна система видеонаблюдения. Первое, что требуется сделать — взять план объекта и проанализировать его на предмет наличия «проблемных» зон. Вспомните — какие инциденты на объекте заставили вас задуматься о CCTV? Где они произошли? Что случилось? Кем были участники этих инцидентов — сотрудники, гости, клиенты, случайные прохожие? Какая информация вам нужна для предотвращения таких ситуаций? Кто и как должен действовать при получении этой информации? Видеонаблюдение действительно может помочь или только создаст иллюзию того, что все под контролем?

Эксплуатационные требования второго уровня помогают проанализировать ряд важных вопросов:

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

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

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

Последний этап — запуск и проверка системы видеонаблюдения первоначальным задачам.

ПРОВЕРКА ПРОЕКТА СИСТЕМЫ

Проверка спецификации системы на соответствие всем решаемым задачам.

ПРИЕМ СИСТЕМЫ В ЭКСПЛУАТАЦИЮ

Соответствие установленного решения как проекту, так и эксплуатационным требованиям.

КОНТРОЛЬ ПРОИЗВОДИТЕЛЬНОСТИ СИСТЕМЫ

Регулярная проверка технических и эксплуатационных характеристик системы с обязательным протоколированием. Контроль производительности желательно отделить от регулярного технического обслуживания.

Существует ряд методик, позволяющих достаточно точно проверить уже установленную систему видеонаблюдения на производительность и возможные ограничения. Для этого используются стандартные цели — Rotakin и тестовые лица. Методика подробно изложена в документе Performance Testing of CCTV. Perimeter Surveillance Systems. (Using the Rotakin Standard Test Target).

Суть тестирования заключается в том, что имеется стандартная цель наблюдения с известными геометрическими размерами и стандартные тестовые лица. Испытания проводят для всех либо части камер, результаты (как объективные для тестовой цели Rotakin — разрешающая способность системы, так и субъективные вероятностные — идентификация тестовых лиц) — заносят в специальные таблицы отчета и выставляют определенные баллы, по которым можно сделать вывод о прохождении или не прохождении испытаний каждой из камер. Отдельно тестируется живое изображение и архивное, потому как последнее может иметь существенно худшие характеристики из-за неправильно выбранных параметров сжатия информации.

8) Выводы

1. Видеонаблюдение — сложная для планирования и внедрения система. Это связано как с необычайно широким перечнем задач, в которых CCTV может быть задействована, так и с отсутствием однозначных объективных критериев качества принимаемых проектных решений.
2. Разработка задания на проектирование / технического задания (ТЗ) / эксплуатационных требований — важнейшая часть создания и внедрения системы видеонаблюдения в операционную деятельность заказчика. Данный документ позволяет детально спланировать все аспекты работы будущей системы для увеличения отдачи от ее внедрения, а также существенно сокращает вероятность возникновения конфликтов между заказчиком и подрядчиком.
3. Есть различные рекомендации по составлению ТЗ. Но не существует единой методики или некоего шаблона ТЗ, подходящего для любого заказчика. Видеонаблюдение очень индивидуальная система, выстраиваемая под потребности и задачи каждого заказчика и учитывающая особенности каждого объекта. Увы, волшебной таблетки тут не водится.
4. Составить ТЗ может как сам заказчик, так и подрядчик, а также независимый консультант. Каждый из этих вариантов не лишен своих недостатков. Наиболее критичный из них — конфликт интересов подрядчика при составлении ТЗ для своего заказчика. В любом случае стоит учитывать, что данная работа весьма трудоемка, требует серьезного погружения в специфику объекта и бизнеса заказчика, поэтому не стоит рассчитывать на качественное выполнение данной работы без отдельной оплаты.
5. Любое ТЗ будет бесполезным, если в нем не предусмотрены механизмы контроля его исполнения. Должна быть разработана методика приемо-сдаточных испытаний с объективными измерениями и оценкой соответствия реально созданной системы первоначальным задачам, ради которых она и внедрялась в бизнес заказчика.