Как создать систему видеонаблюдения. Шаг 2. От концепции к заданию на проектирование
Уважаемые читатели Low-voltage Blog! В предыдущей статье мы задали себе 5 блоков вопросов по созданию системы видеонаблюдения и получили в итоге концепцию будущей системы. Список её потребительских качеств и свойств. Далее вам необходимо согласовать задание на проектирование вашей будущей системы видеонаблюдения.
Более подробная новая статья по заданию на проектирование / ТЗ — Задание на проектирование — важнейший документ на который все плюют.
Содержание:
1. Вы поручаете подготовку задания на проектирование системы видеонаблюдения собственной службе заказчика, службе безопасности или службе эксплуатации
2. Вы поручаете подготовку задания на проектирование системы видеонаблюдения выбранному вами заранее подрядчику по проектированию
3. Вы поручаете подготовку задания на проектирование системы видеонаблюдения стороннему независимому консультанту, который выполнит данную работу на коммерческих условиях
- Создание задания на проектирование. Нормативная база
- Элементы задания на проектирование. Желательные и не желательные
- Основные технико-экономические показатели системы видеонаблюдения. Перевод бизнес-требований концепции в технические требования задания на проектирование
1. Сформулируйте для чего Вам нужна система видеонаблюдения предельно конкретно.
1.1 Список контролируемых зон
1.2 Требования по удобству эксплуатации системы в целом и эргономике рабочих мест в частности
2. Какое место в ваших бизнес-процессах займет видеонаблюдение?
2.1 Список сценариев использования системы видеонаблюдения
2.2 Список IT-систем и систем безопасности, подлежащих интеграции с системой видеонаблюдени
3. Какое время вы сможете временно обходиться без системы видеонаблюдения в случае её технического обслуживания или ремонта?
3.1 Требования доступности функций системы видеонаблюдения в течении заданного времени
3.2 Требования по удобству обслуживания системы в целом и отдельно центрального и периферийного оборудования.
4. Какое время планируется владеть данной системой без её существенной модернизации?
4.1 Сценарий владения системой видеонаблюдения
5. Нужно ли учитывать существующее у вас оборудование (инфраструктуру) при проектировании системы видеонаблюдения?
5.1 Список существующего оборудования заказчика, доступного для применения в системе видеонаблюдения
Кому адресован этот блог и почему моему мнению можно доверять.
Мои контакты — пишите по любым интересующим вопросам, в том числе предложения о сотрудничестве.
Внимание! Статья содержит много информации и потребует время на изучение. Для удобства посетителей моего блога планируется создание видео-обзора данной темы на собственном канале youtube. Следите за новостями в блоге!
Для тех, кто не читал первую статью серии:
Виденаблюдение — одна из самых востребованных слаботочных систем. И это неудивительно — от 70% до более 90% информации человек получает с помощью зрения, поэтому подсознательно заказчик рассчитывает получить от данной слаботочной системы максимальный эффект.
В данной статье мы ответим себе на самые важные вопросы о целях и задачах, которые мы поручим системе видеонаблюдения.
Почему это важно сделать? Задание на проектирование переводит язык бизнес-требований к системе видеонаблюдения, сформулированный в концепции, в язык технических требований к системе, количественным показателям, KPI — если KPI не было сформулировано на этапе концепции.
Кто составляет задание на проектирование?
На этапе подготовки задания на проектирование у вас есть несколько опций. Вы можете поручить создание задания на проектирование системы видеонаблюдения вашим сотрудникам, компетентным в данном вопросе (например у вас есть служба заказчика или служба эксплуатации). Вы можете обратиться к заранее выбранному подрядчику, который создаст задание на проектирование и согласует с вами (или вашими техническими специалистами). Либо вы можете обратиться к стороннему независимому консультанту, который выполнит данную работу на коммерческих условиях (обычно подрядчик не берет отдельно плату за задание на проектирование, это идёт бонусом).
Каждый из приведенных вариантов имеет полное право на существование и имеет как достоинства, так и недостатки. Давайте рассмотрим варианты подробней.
1. Вы поручаете подготовку задания на проектирование системы видеонаблюдения собственной службе заказчика, службе безопасности или службе эксплуатации
Преимущества:
- ваши сотрудники лучше знают особенности вашего объекта (если он уже построен) и ваших бизнес-процессов, планов и т.п.;
- ваши сотрудники заинтересованы в долгосрочном успехе проекта, являются заинтересованной стороной (службе эксплуатации нужно чтобы легко и эффективно можно было поддерживать работоспособность системы, службе безопасности — получить эффективный инструмент повседневной деятельности и т.п.);
- не требует отдельных материальных затрат, только время ваших сотрудников;
- максимально удобно для заказчика (минимум времени на согласование, возможность делегирования, отсутствие необходимости заключать какие-либо дополнительные договоры);
- ваши сотрудники могут подготовить задание на проектирование в том числе в расчёте на конкурсные процедуры выбора подрядчика.
Недостатки:
- далеко не у всех есть служба безопасности, служба заказчика, служба эксплуатации и др. сотрудники, по долгу службы связанные с дальнейшей работой или эксплуатацией системы видеонаблюдения;
- далеко не все ваши сотрудники хорошо осведомлены о всех нюансах проектирования систем видеонаблюдения и о самих системах видеонаблюдения — т.е. вопрос качества получившегося документа;
- не исключена возможность саботажа при составлении требований системы видеонаблюдения собственными сотрудниками, если существует скрытый конфликт интересов;
- есть риски затянуть стадию согласования задания на проектирование из-за плохого взаимодействия сторон процесса (заказчика, службы заказчика, подрядчика).
2. Вы поручаете подготовку задания на проектирование системы видеонаблюдения выбранному вами заранее подрядчику по проектированию
Преимущества:
- подрядчик по проектированию в общем случае имеет неплохие компетенции по созданию систем видеонаблюдения;
- не требует отдельных материальных затрат, потому как стоимость работ по созданию задания на проектирование обычно входит в общую стоимость проектирования;
- скорость создания задания на проектирование будет максимально возможной, т.к. подрядчик заинтересован быстрее приступить к основной части подряда, в отличии от собственных сотрудников заказчика, да и независимого консультанта.
Недостатки:
- может возникнуть конфликт интересов подрядчика по отношению к требованиям концепции заказчика — например, какие то требования концепции могут потребовать от подрядчика больших сроков как на создание задания на проектирование, так и на само проектирование;
- другой пример конфликта интересов — подрядчик может быть заинтересован в лоббировании определенной продукции или программного обеспечения на стадии проектирования и исходя из собственных интересов закладывать требования в задании на проектирование;
- подрядчик не сильно заинтересован в долгосрочном успехе проекта — ему в дальнейшем не нужно будет эксплуатировать и поддерживать в рабочем состоянии систему видеонаблюдения (исключая гарантийный период, но он мал по сравнению с общим сроком эксплуатации), поэтому у подрядчика есть соблазн сэкономить на удобстве эксплуатации и функциональности.
3. Вы поручаете подготовку задания на проектирование системы видеонаблюдения стороннему независимому консультанту, который выполнит данную работу на коммерческих условиях
Преимущества:
- независимый консультант (при наличии соответствующего опыта) может наиболее точно из всех перевести бизнес-требования концепции в технические требования к системе;
- независимый консультант заинтересован в качестве задания на проектирование, потому как основной его актив — профессиональная репутация;
- независимый консультант чаще всего не имеет конфликта интересов с заказчиком, потому как не выполняет других работ по проектированию и строительству, а только осуществляет консультации;
- независимый консультант может подготовить задание на проектирование в том числе в расчёте на конкурсные процедуры выбора подрядчика.
Недостатки:
- необходимо потратить дополнительное время на поиски подходящего консультанта, заключения дополнительных договорных обязательств и т.п.
- наличие независимого консультанта может привести к увеличению сроков согласования задания на проектирование со всеми заинтересованными сторонами;
- наличие независимого консультанта потребует от заказчика дополнительного финансирования.
Независимо от того, какой в итоге вариант вы выбрали вам необходимо будет рассмотреть и согласовать получившийся итоговый документ. Для этого вам потребуются некоторые дополнительные сведения о том как данный документ должен выглядеть, что он должен в себя включать и как проверить адекватность перевода концепции системы видеонаблюдения на язык технических требований к данной системе. Итак, рассмотрим данные аспекты подробней.
Создание задания на проектирование. Нормативная база
К сожалению в отечественной нормативной базе отсутствует документ, содержащий исчерпывающие требования по составлению задания на проектирование системы видеонаблюдения. (Update. Вообще есть рекомендации МВД Р 78.36.008-99 — хороший документ, только несколько устаревший. Но он всё же не совсем про задание на проектирование). Тем не менее, некоторые ориентиры можно почерпнуть из следующих нормативных документов: Гражданский кодекс РФ (ч.2) от 26.01.1996 № 14-ФЗ, статья 759; Градостроительный кодекс РФ от 29.12.2004 № 190-ФЗ, статья 48 ч.5; Постановление Правительства РФ от 16 февраля 2008 г. № 87; Технический регламент о безопасности зданий и сооружений, статья 4 ч11; РД 25.952-90 Приложения 1-3, 7; СНиП 11-01-95, Приложение Б. Из этих документов вам скорее всего будет понятно… что ничего не понятно 🙂 . Но вы не расстраивайтесь, ведь и сами проектировщики в этих плохо согласованных между собой документах мало что понимают, так что лучше руководствоваться здравым смыслом 🙂 .
Самым важным из перечисленных документов является последний СНиП 11-01-95, Приложение Б — я бы советовал принять его как некоторый базис, отталкиваясь от которого ваш исполнитель (кем бы он не был) должен будет составить задание на проектирование. Только не забывайте, что данный документ уже утратил силу. Альтернативный вариант — взять за основу РД 25.952-90 — так же вполне годный документ. Опять таки не забываем, что РД 25.952-90 уже несколько устарел (например стадийность проектирования после вступления в силу Постановления Правительства РФ от 16 февраля 2008 г. № 87 понимается несколько иначе). Ну и вдобавок оба предложенных мною варианта не подходят, чтобы взять “как есть” — необходимо внести специфику именно видеонаблюдения.
Элементы задания на проектирование. Желательные и не желательные
Давайте немного порассуждаем какие элементы задания на проектирование важны. И очень желательно, чтобы они присутствовали. А какие элементы только загромождают общую конструкцию. И лучше чтоб их не было совсем.
Начнём с того, что лучше из задания на проектирование исключить:
- цели создания системы видеонаблюдения в задании на проектирование должны совпадать с целями, выявленными на этапе составления концепции. Цели, которые невозможно перевести в числа (в тот же KPI) должны быть исключены или переформулированы;
- в задании на проектирование стоит избегать упоминания конкретных марок оборудования. Если только это не марки существующего у заказчика оборудования, которое необходимо учесть при проектировании;
- в задании на проектирование стоит избегать излишней детализации требований к оборудованию, которая исключает вариативность проектирования. Вместо этого детально нужно описывать потребительские свойства и эксплуатационные качества всей системы видеонаблюдения в целом. Взаимосвязи с другими инженерными и IT системами (если они есть). Показатели надёжности системы (коэффициент готовности, минимальную наработку на отказ отдельных узлов системы).
Перейдем к моментам, которые очень желательно в задании на проектировании отразить:
- основание для выполнения работ (Федеральная целевая программа, Программа развития субъекта РФ, Программа развития муниципального образования, Ведомственная целевая программа, Решение Президента РФ, Правительства РФ, органов государственной власти субъектов РФ и органов местного самоуправления в соответствии с их полномочиями, Решение застройщика, собственника);
- вид строительства (новое, реконструкция, техническое перевооружение, расширение);
- сроки проектирования;
- требования по вариантной и конкурсной разработке (указать, если требуется выполнение сравнения вариантов проектных решений);
- особые условия строительства (климатические условия и др.);
- тип разрабатываемой документации (проектная или рабочая) и порядок её разработки при заказе документации обоих типов (разработка рабочей документации после получения положительного заключения экспертизы или одновременная разработка проектной и рабочей документации);
- выделение очередей и пусковых комплексов, требования по перспективному расширению системы (при наличии таких требований);
- требования к методу составления сметной документации (базисно-индексный метод, ресурсный метод – в текущий ценах);
- требования по выполнению опытно-конструкторских и научно-исследовательских работ в процессе проектирования и строительства (при наличии каких то особо экзотических требований и уникальных задач);
- требования по выполнению демонстрационных материалов (в случае необходимости выполнения макета объекта, 3D презентаций, демонстрационных альбомов и так далее с указанием требований к демонстрационным материалам);
- специальные технические требования на которые отсутствуют нормативные требования (при наличии таких требований);
- требования к составу и содержанию документации (для рабочей документации — обязательно, для разделов 6, 11, 5 и 9 проектной документации — желательно при финансировании из средств застройщика / собственника), к оформлению документации, количеству экземпляров и наличию электронной копии, прочие условия заказчика по разработке документации (например требование приложить сертификаты пожарной безопасности на оборудование и материалы);
- исходные данные для проектирования (перечислить прилагаемые к заданию на проектирование генплан или выкопировку из генплана, чертежи архитектурно-строительные: планы, разрезы, геоподосновы с нанесением инженерных сетей и т.п.);
- основные технико-экономические показатели системы (подробней чуть ниже);
- требования о необходимости осуществления авторского надзора (при необходимости);
- требование составить перечень предоставляемой производителем работ исполнительной документации (согласно РД 11-02-2006) и приемо-сдаточной документации (при необходимости).
После того как мы пробежались по всем пунктам, которые необходимо осветить в задании на проектирование осталось проверить адекватность перевода концепции системы видеонаблюдения на язык технических требований, т.е. подробней посмотрим на пункт “основные технико-экономические показатели системы”.
Основные технико-экономические показатели системы видеонаблюдения. Перевод бизнес-требований концепции в технические требования задания на проектирование
В прошлой статье мы рассмотрели 5 блоков вопросов, которые необходимо отразить в концепции на проектирование. Давайте сопоставим эти блоки вопросов с KPI, которые необходимо отразить в основных технико-экономических показателях системы.
1. Сформулируйте для чего вам нужна система видеонаблюдения предельно конкретно
Какое изображение Вы хотите получить, как именно его использовать, когда (после какого то события, регулярно, постоянно) и где (в той же локации, где будет камера или где то ещё).
1.1 Список контролируемых зон
Для каждой зоны должны быть указаны:
- описание задачи, решаемой видеоконтролем (в реальном времени, на записи), в том числе описание минимально необходимого количества кадров/сек.;
- соотношение пиксель/метр (по стандарту EN 50 132-7). Для определения адекватности данного соотношения можно воспользоваться критериями полиции Великобритании Home Office Scientific Development Branch 2009 , ныне Centre for Applied Science and Technology (и вот ещё ссылочка 🙂 ). Ну и, в довесок, уже упоминавшиеся рекомендации МВД Р 78.36.008-99;
- режим записи (после какого то события, регулярно, постоянно);
- требования к времени хранения записи (т.н. “глубина архива”), наличию резервирования записи, качеству основной и резервной копий записи, локации основного и резервного хранилища данных видеонаблюдения;
- минимальная и максимальная освещенность в светлое и темное время суток;
- особенности контролируемых зон, влияющие на проектирование (оптическая плотность среды, агрессивность окружающей среды, температурный диапазон, электромагнитная обстановка, необходимость грозозащиты, необходимость вандалозащищенности, необходимость аудио-контроля зоны и т.п.) — при необходимости;
- юридические аспекты видеонаблюдения (требования к наличию приватных зон; требования к формату сжатия видеопотока и т.п.) — при необходимости;
- список пользователей с указанием прав (просмотр по расписанию, возможности экспорта/ сохранения/ удаления видео фрагментов) и с указанием их локации (присутствуют на объекте видеонаблюдения и где конкретно или удаленное видеонаблюдение через глобальную сеть интернет).
Данные пункты указать индивидуально для каждой отдельной зоны, либо для группы зон.
1.2 Требования по удобству эксплуатации системы в целом и эргономике рабочих мест в частности
Например:
- максимальное количество видео-потоков на один монитор;
- минимально-допустимое разрешение видео-потока в многооконном и в полно-экранном режимах;
- минимально-допустимое количество кадров в секунду для просмотра в режиме “реального” времени и в режиме архива;
- требования по автоматизации действий персонала в программном обеспечении системы видеонаблюдения (использование одной учётной записи для входа в разные программные продукты; составление карточек событий, отчётов; программные сценарии действий при тревогах и т.п.).
2. Какое место в ваших бизнес-процессах займет видеонаблюдение?
Будет ли оно жить автономно от других IT-систем и систем безопасности, или должно быть с ними взаимосвязано? Как именно различные системы безопасности и IT-системы должны взаимодействовать? Опишите сценарий такого взаимодействия. Нужны ли вам функции видеоаналитики?
2.1 Список сценариев использования системы видеонаблюдения
Например:
- расследование инцидентов, сбор доказательств;
- контроль оперативной обстановки;
- верификация (подтверждение) событий систем охранной сигнализации, технических средств охраны периметра;
- верификация событий систем пожарной сигнализации, контроль процедуры эвакуации персонала при пожаре;
- верификация событий системы контроля доступа;
- верификация событий систем управления зданием (автоматики, диспетчеризации);
- контроль кассовых операций;
- использование функций видео-аналитики в дополнение к техническим средствам охраны периметра и системам охранной сигнализации;
- использование функций видео-аналитики в дополнение к системе пожарной сигнализации;
- использование функций видео-аналитики в дополнение к системе контроля доступа (в том числе системам контроля проезда и системам управления движением для паркингов);
- использование функций бизнес-аналитики для ритейла, сферы услуг, банков (подсчёт посетителей, анализ людей в очереди, анализ поведения клиентов);
- использование функций видео-аналитики для автоматизации работы постов видеонаблюдения (использование операторов только для подтверждения тревог, автоматически определяемых модулем видео-аналитики; автоматическое управление поворотными видеокамерами, захват целей наблюдения);
- использование функций видео-аналитики для автоматизации процесса расследования инцидентов (автоматизация поиска в архиве, функции ускорения просмотра длинных фрагментов — т.н. video synopsis и др.).
2.2 Список IT-систем и систем безопасности, подлежащих интеграции с системой видеонаблюдения
Для каждой системы указать:
- используемое центральное (серверное) программное обеспечение (ПО), его версию, установленные service pack-и и т.п.;
- наличие стандартных открытых протоколов (в том числе промышленных) или интерфейсов для обмена данными c внешними информационными системами (BACnet, LonWorks, Modbus (RTU), EIB/KNX; OPC (DA), SNMP; XML) либо API для интеграции;
- список событий и команд, доступных для использования в сторонних информационных системах.
3. Какое время вы сможете временно обходиться без системы видеонаблюдения в случае её технического обслуживания или ремонта?
Какие при этом придётся предпринять меры, как это скажется на вашем бизнесе, какие несет риски потерь (материальных, моральных, имиджевых и т.п.)?
3.1 Требования доступности функций системы видеонаблюдения в течении заданного времени
- коэффициент готовности (Instantaneous availability function) по ГОСТ 27.002-89 для системы в целом или отдельно по центральному и периферийному оборудованию;
- средняя наработка на отка́з (англ. Mean time between failures, MTBF) для отдельных узлов системы видеонаблюдения (не менеше данного значения) — при необходимости;
- среднее времени восстановления (англ. Mean time to repair MTTR) для отдельных узлов системы видеонаблюдения (не больше данного значения) — при необходимости.
3.2 Требования по удобству обслуживания системы в целом и отдельно центрального и периферийного оборудования
Может включать в себя:
- общие эксплуатационные требования (см., например, Р 78.36.008-99);
- требования к расположению периферийного оборудования и удобству его обслуживания;
- требования к расположению центрального оборудования и удобству его обслуживания.
4. Какое время планируется владеть данной системой без её существенной модернизации?
Планируется ли расширение системы, будут ли ей добавляться новые функции, какова должна быть стоимость владения данной системой для эффективности ваших инвестиций?
4.1 Сценарий владения системой видеонаблюдения
Может включать в себя:
- примерный график расширения системы (сроки, локация, примерный % увеличения системы, изменение сценариев использования системы видеонаблюдения и т.п.)
- требования по коэффициенту окупаемости инвестиций ROI (Return On Investment) с учётом затрат на закупку оборудования, монтаж, пусконаладку, техническую эксплуатацию, расширение и модернизацию системы (при необходимости подтвердить расчётом при проектировании) — при необходимости;
- требования по совокупной стоимости владенияTCO (total cost of ownership) — при необходимости;
- список технологий, желательных для применения при проектировании (стандарты передачи и сжатия сигналов видеонаблюдения, стандарты систем хранения данных, стандарты систем связи и т.п.).
5. Нужно ли учитывать существующее у вас оборудование (инфраструктуру) при проектировании системы видеонаблюдения?
5.1 Список существующего оборудования заказчика, доступного для применения в системе видеонаблюдения.
Для каждой единицы оборудования указать:
- марку и производителя, установленное на нём программное обеспечение и его версию;
- основные технические характеристики оборудования;
- локацию оборудования;
- какую функцию оборудование решает в настоящий момент, % его использования.
Что ещё необходимо отразить в задании на проектирование?
Для начала проектных работ необходимо выдать проектировщику исходные данные (мы уже касались этого, речь о планировках, генплане, геоподоснове и т.п.); технические условия на подключение к системе электроснабжения; требования к категории электроснабжения, заземлению оборудования; технические условия на подключение системы видеонаблюдения к существующим каналам связи (интернет, ЛВС, ВОЛС и т.п.) и любые иные требования, которые необходимо учесть при проектировании (вплоть до требований к эстетике и требования согласовать расположение периферийного оборудования с дизайнерами Заказчика).
В завершении хочу отметить, что данный этап создания системы видеонаблюдения крайне важен. Советую уважаемым Заказчикам внимательно следить за полнотой подписываемого задания на проектирование. В дальнейшем будет очень сложно доказать что построенная система не соответствует Вашим ожиданиям, если эти ожидания не прописаны очень скрупулезно и конкретно (т.е. выражено в цифрах).
Отдельно должен заметить, что составить все перечисленные мной выше документы на практике не возможно для средних и мелких объектов, и даже для большей части крупных. Это слишком трудозатратный процесс, поэтому весьма дорогой. Но какие то основные элементы данного списка можно и нужно использовать в реальных кейсах. Нужно ориентироваться по конкретной ситуации, объекту, задаче — какими из приведенных мною рекомендаций стоит воспользоваться, а что можно и пропустить.
На сегодня эта вся информация, которой я хотел с вами поделиться, спасибо за уделенное время!
На следующем шаге мы рассмотрим дальнейшие действия по созданию и согласованию проектной и рабочей документации.
В статье использована иллюстрация, специально подготовленная для блога моей супругой Озеровой Екатериной. Катенька, большое спасибо за помощь и поддержку!
Уважаемые читатели блога, если Вы заметили в статье неточность, сложность в изложении материала либо некорректность используемых терминов — прошу написать в комментариях либо в личном сообщении, все замечания будут обязательно учтены и по-возможности исправлены все недочёты.
Жду ваших вопросов, комментариев и предложений.
Жмите кнопки социальных сетей, подписывайтесь на email рассылку, добавляйте блог в свою RSS-ленту, вступайте в группы блога в социальных сетях!
Все материалы данного блога принадлежат его автору. Использование без ссылки на данный блог с указанием авторства не допускается!
Похожие статьи
Евгений, есть несколько вопросов.
1) «в задании на проектирование стоит избегать излишней детализации требований к оборудованию, которая исключает вариативность проектирования»
О какой вариативности идет речь при выполнении ПД? В моем понимании все варианты и их технико-экономическая оценка производятся на этапе концептуального проектирования. Линейка применимого оборудования должна быть, согласен, чтобы можно было провести закупки в условиях конкурентной среды, а не быть привязанным к одном поставщику, но в остальном…А в РД и вовсе оборудование должно быть определено оборудование и указано в спецификации.
2) Не очень понимаю важность упоминания в ТЗ на проектирование основания для строительства. Если Заказчик заключает договор и готов исполнять его условия так ли важна формальная сторона.
3) На мой взгляд довольно существенный момент, который влияет на состав и содержание ТЗ- это является ли система видеонаблюдения отдельным проектом или это часть какого-то бОльшего проекта (реконструкции или строительства). Вероятно подходы, детализация этих вариантов могут значительно различаться.
Вы выделили очень важный момент- привлечение к разработке ТЗ эксплуатирующей организации (персонала). Не знаю как с системой видеонаблюдения, но в целом для строительного проекта бывает полезным привлекать к строителей, которые могут сказать свое веское слово с позиции реализуемости проекта. Возможно вполне резонно они могут принять участие и в разработке ТЗ, чтобы более полно охватить требования (привязаться к реальным условиям площадки).
Еще раз спасибо за статью.
Еще один момент:
«требования по коэффициенту окупаемости инвестиций ROI (Return On Investment) с учётом затрат на закупку оборудования, монтаж, пусконаладку, техническую эксплуатацию, расширение и модернизацию системы (при необходимости подтвердить расчётом при проектировании);»
Система видеонаблюдения (во всяком случае иного не видел) является вспомогательной в составе других процессов или продуктов, т.е. она обеспечивает некие требования, но не является источником выручки и прибыли. Поэтому не понятно каким образом может быть обеспечен возврат инвестиций. В данном случае скорее применим показатель TCO (total cost of ownership). Когда идет сравнение сопоставимы по функциональным способностям систем по критерию общей стоимости (капитальные затраты, затраты на эксплуатацию и ремонт, иногда последующая замена в части затрат на демонтаж). По наименьшей стоимости выбирается вариант. Но это опять же традиционно выполняется на этапе вариантных оценок.
Михаил, по поводу ROI — да, возможно вы правы. Хотя сейчас видеонаблюдение очень часто начинает решать такие задачи — которые раньше перед ней не ставились. Например, бизнес функции видеоаналитики, связанных с маркетингом — подсчёт количества посетителей, пол, вес, «горячие зоны» магазина и т.п. И тут уже ROI вполне считается.
Про показатель TCO (total cost of ownership) — не знал, спасибо, почитаю, добавлю в статью (с вашего позволения).
Михаил, спасибо за столь содержательный комментарий.
По п.1. В данной статье обсуждаем только задание на проектирование. Такого понятия как «концептуальное проектирование» в Законодательстве и нормативных документах нет. У проектной документации есть две основные функции — 1) согласовать основные технические решения с экспертизой на предмет оценки соответствия принятых решений требованиям законодательства, нормативным правовым актам, документам в области стандартизации (п.3.1.2 ГОСТ Р 21.1001-2009) — правда требуется для случая, когда данные технические решения оказывают влияние на безопасность объектов капитального строительства 2) утвердить основные технические решения заказчиком на предмет оценки соответствия принятых решений заданию на проектирование. И в этом случае у проектировщика на этапе создания проектной документации могут быть развязаны руки (и я считаю это правильным) по выбору оборудования под требования технического задания (требования законодательства — это само собой разумеется). Возникает конечно вопрос о критерии выбора проектировщика. И рискну предположить, что именно об этом Вы и и говорили — «концептуальное проектирование» — это проектирование для формирования коммерческого предложения на создание как документации, так и монтажа и наладки системы? Если так — то да, Ваша мысль тогда понятна. Но всё равно — мы же говорим про задание на проектирование. Его должен составить заказчик (его представители или нанятый им эксперт / организация) — в идеале, а не выбранный по непонятным критериям подрядчик. Если мы в задании на проектирование зададим очень жёсткие требования к отдельным узлам оборудования или того хуже вообще укажем конкретную марку — тогда всё, про конкурсный выбор проектировщика и подрядчика можно сразу забыть. Выиграть его за счёт более «умного» проектирования будет невозможно. Я имел ввиду именно это.
Не претендую на истину в конечной инстанции. Я считаю наиболее правильным такой подход — 1) до составления задания на проектирование определяем решаемые системой задачи 2) в задании на проектирование переводим выявленные на предварительном этапе бизнес-требования в требования технические к системе в целом, а не отдельным узлам (нам нет дела до отдельных узлов системы, нашу бизнес-задачу решает система в целом). 3) устраиваем конкурс по выбору проектировщика. 4) создаем, согласовываем и утверждаем проектную документацию 5) устраиваем конкурс на выбор подрядчика 6) создаем и утверждаем рабочую документацию 7) строим, делаем исполнительную документацию. 8) сдаём объект в эксплуатацию, делаем всю оставшуюся приёмо-сдаточную документацию 9) эксплуатируем объект
По п.2 — в статье «полное собрание сочинений». В конце я написал — «отдельно должен заметить, что составить все перечисленные мной выше документы на практике не возможно для средних и мелких объектов, и даже для большей части крупных. Это слишком трудозатратный процесс, поэтому весьма дорогой. Но какие то основные элементы данного списка можно и нужно использовать в реальных кейсах. Нужно ориентироваться по конкретной ситуации, объекту, задаче — какими из приведенных мною рекомендаций стоит воспользоваться, а что можно и пропустить. Т.е. данный пункт — если не нужен — смело пропускаем и всё, он появился из СНиП 11-01-95, Приложение Б»
По п.3 Да, наверное Вы правы. Естественно, влияет.