Формирование системы комплексной безопасности. Часть 2


Скачать

Часть 2

Подготовка техзадания и проектирование

Алексей Омельянчук. Нач. КБ Рубикон ООО «СИГМА-ИС».


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

Формулировка требований к комплексной системе

Если задание на систему сформулировано не в виде "120 видеокамер и 29 участков "Багульника", а как описание охранных задач, то отдельно описывать требования на интеграцию не так уж и нужно. Неинтегрированная система просто не сможет эффективно решить за указанное время даже простейшие задачи охраны - обнаружение и предотвращение проникновения.

Еще один способ косвенно описать требования к интеграции - указать предполагаемый состав АРМ и решаемые ими задачи. Так, если указано, что в случае возникновения нештатной ситуации начальник СБ должен на своем рабочем месте не позднее получаса после возникновения инцидента заархивировать на съемный носитель всю информацию, поступившую за последние сутки, опечатать ее в присутствии комиссии и уложить в сейф, то это может служить подтверждением необходимости полной интегрированности системы. Интеграция (как и установка заданного количества видеокамер или интеграция оборудования каким-то самым "модным" образом) -это не самоцель. Даже пресловутая "мебельная интеграция", когда на один стол устанавливают АРМы от разных подсистем и называют это "интегрированным АРМ", тоже может быть приемлемой, если при этом удовлетворительно решаются задачи на конкретном объекте.

Обслуживание системы


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

Обучение персонала

Упомяну также о том, что персонал, которому предстоит обслуживать систему, нужно предварительно обучить. Предоставление учебной документации (или как минимум инструкций оператора для каждого рабочего места) должно быть обязательно оговорено, иначе вы рискуете получить пачку РЭ на смонтированное оборудование и получасовой беглый показ "что и как работает".

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


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

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

Надежность системы

Еще одна категория требований, которые очень важны и вызывают много споров, - это требования к надежности системы.

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

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

Этапы работы над техническим заданием

Повторюсь: проектирование - творческая работа; ее невозможно строго распланировать, можно проводить только в несколько последовательных итераций, постепенно приближаясь к оптимальному результату, согласовывая с заказчиком промежуточные варианты Даже ГОСТы серий 2 и 21 предусматривают несколько этапов - техпредложение, эскизный проект, рабочий проект стадии "О" и так далее. Для сложных систем следует потребовать в качестве отдельных этапов выделить как минимум техпредложение и эскизный проект.

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

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

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

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

Задание заказчику

Еще одна существенная часть проекта интегрированной (комплексной) системы безопасности - задание заказчику.

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

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

 

Обязанности заказчика

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


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

Очень часто в результате все равно выяснится, что чертежи зданий имеются только те, что выполнены "в 1957 г.", но с той поры прошло 17 реконструкций и от первоначальных стен остались лишь несколько подпорок. Может оказаться, что и топографическая съемка проводилась тоже 50 лет назад, с того времени один овраг засыпали, зато вырос другой. Однако даже подобные исходные данные должны быть предоставлены, а их качество может стать причиной, по которой подрядчик потребует дополнительных денег на повторное проведение обмеров помещений, а то и на гидрогеологическое обследование территории.

Нормативные документы

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

НПБ (вскоре будут преобразованы в своды правил пожарной безопасности) обязательны в части противопожарных работ, основополагающим документом здесь в первую очередь является НПБ 88-2001.

Обязательно должны соблюдаться и некоторые ГОСТы, например ГОСТ Р 50776-95, содержащий довольно общие требования. Применение ГОСТов серий 34 и 24 (автоматизированные системы) к комплексным системам безопасности спорно, однако крупный заказчик, несомненно, передаст проект на отзыв в свое ИТ-подразделение, и радуйтесь, если вам не придется выполнять требования ITIL. Наиболее детальным (и полезным) в этой серии является вспомогательный документ - РД 50-34.698-90 - "Автоматизированные системы. Требования к содержанию документов".

Самое большое количество нормативных документов по охранным системам выпущено МВД (или ГУВО). Это РД серии 78. В частности, РД 78.36.003-2002, РД 78.36.005-2005, Р 78.36.008-99, ТТ 78.36.001-99 и др. Эти документы вообще никого ни к чему не обязывают, тем более что они ведомственные и напрямую относятся только к объектам, принимаемым на охрану вневедомственной охраной. Тем не менее, за отсутствием других, они широко применяются любыми заказчиками, как частными, так и государственными.

Проектирование - работа творческая, ее нужно планировать итеративно, с коррекцией и уточнением требований после каждого этапа


Учитывая тот факт, что применение большинства упомянутых документов в большинстве случаев спорно, лучше указать в ТЗ, какие нормы должны быть выполнены безусловно (как правило, это НПБ), а от каких допускаются согласованные отклонения - это обычно относится к ГОСТ 2 (ЕСКД) в части состава и оформления документов, ибо многие документы сейчас предоставляются на компьютерных носителях (в таком случае должен быть согласован их формат).

Распространенным соглашением является предоставление документов в формате AutoCAD, подготовленных к распечатке, так, чтобы бумажные копии соответствовали ЕСКД. Нередко требуется предоставление дублирующих копий в более надежно совместимом формате PDF.

Распространена формулировка "с учетом требований РД 78.36.003-2002, РД такого-то и такого-то". Это обязывает проектировщика как минимум упомянуть о том, какие требования учтены, а какие сознательно проигнорированы.

Основные моменты при составлении технического задания

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

  1. Исходные требования лучше задавать именно те, которые нужны пользователю - охранные, а не вторичные (технические)
  2. Выполнение всех требований должно контролироваться. Эту обязанность (разработка методик проверки выполнения требований) можно и нужно также явно возложить на проектировщика, методики приемки должны быть в составе проектной документации
  3. Не забыть обязать проектировщика провести всевозможные расчеты и обоснования, анализ угроз, описание предполагаемых алгоритмов действий службы безопасности при тревоге и так далее.
  4. Лучше четко перечислить состав разрабатываемой проектной документации, ведь даже ГОСТ-21 допускает большую свободу в отнесении отдельных видов документов к обязательным, а уж общий ГОСТ-2 вообще считает обязательным только "спецификацию", чего, безусловно, недостаточно. Необходимым минимумом можно считать планы размещения оборудования и кабельных трасс, схемы подключения оборудования, кабельные журналы. Крайне желательны документы типа "расчет" или "обоснование", в которых проводятся: трехмерный анализ покрытия территории видеокамерами или зонами чувствительности датчиков, расчет карты освещенности, расчет систем питания и выбора кабелей. И, конечно, упомянутые выше анализы - анализ угроз, анализ надежности, расчет штата службы эксплуатации. Желательны описания конфигураций (настроек) отдельных элементов оборудования

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

Источник: Журнал "Системы безопасности" №2, 2009

Архив публикаций