1. Статьи
2. Решения систем безопасности
3. Некоторые особенности реализации крупныхинфраструктурных проектов

Башков Владимир Анатольевич, руководитель группы проектных решений Bosch Системы Безопасности

Любой проект считается уникальным. Это, собственно, следует из самого определения слова — проект. Однако даже для крупных инфраструктурных проектов систем безопасности, отличающихся высокой сложностью и многокомпонентностью, можно выделить некоторые схожие черты. Речь не идет о типовых стадиях и областях проекта, описанных в PMBOK, а скорее о тех нюансах, которые, как правило, нигде не упоминаются, но часто возникают в реальной жизни. Рассмотрим некоторые из таких задач.

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

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

Всесезонный горный курорт «Горки Город», Красная Поляна, Сочи

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

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

Технопарк «Сколково», Москва

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

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

- Четкое определение требований к работе системы и понимание решаемых с ее помощью задач.

- Использование BIM (Building Information Modeling) при разработке документации. Это позволит обеспечить детальную проработку как отдельных элементов, так и корректное сопряжение всех подсистем. Кроме того, BIM-модель проекта значительно упростит эксплуатацию системы. Многие производители уже готовы предоставить достаточно обширные BIM-библиотеки на свое оборудование и при необходимости разрабатывать под проект требуемые BIM-модели оборудования.

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

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

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

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

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

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

Стадион ФК «Краснодар», Краснодар

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

В настоящее время, пожалуй, ни один вендор на рынке не может предложить решение, закрывающее все потребности заказчика в такого рода проектах, даже в части систем безопасности, не говоря уж о смежных системах. И в текущей ситуации крайне важным становится открытость системы. Конечно же удобно, когда решение уже содержит прединтегрированные ключевые элементы, такие как видеонаблюдение, СКУД, охранная и пожарная сигнализация. Это позволяет сфокусироваться на интеграции со сторонними системами. Довольно часто возникает необходимость в интеграции с системами СМИС (структурированная система мониторинга и управления инженерными системами зданий и сооружений) и СМИК (система мониторинга инженерных конструкций) или специализированными системами, уникальными д ля каждого вертикального рынка, как, например, интеграция видеонаблюдения с системой транспортировки багажа в аэропорту или системой подсчета купюр в хранилище банка. И здесь крайне важна не только поддержка открытых интерфейсов и стандартныхпротоколов, но и готовность производителей к интеграции своих систем.
Ведь зачастую даже поддержка одной и той же версии протокола OPC(Open Platform Communications) илиONVIF(Open Network Video Inter faceForum) не гарантирует успешную интеграцию. В таких ситуациях важнуюроль играет позиция заказчика, который может определить требованияк интеграции и выступить «катализатором» во взаимодействии различныхвендоров. Таким образом, без тесного взаимодействия заказчика и всехучастников проекта опять никуда.

В последнее время с развитием облачных технологий набирает популярность такое направление как Video-asaservice и Security-as-a-service, когда заказчик платит не за камеру, а за картинку, не за датчик, а за сигнал тревоги. И многие начинают рассуждать о том, что данный подход мог бы решить большую часть описанных выше проблем. Это и понятно. В конечном итоге заказчик хочет получить предсказуемый результат с заданной стоимостью капитальных вложений и стоимостью владения. Т.е. безопасность как сервис, а может и анализ бизнес-процессов как сервис, когда заказчик оформляет абонентскую подписку и получает инструмент, заточенный под решение своих бизнес-задач. Рынок уже активно развивается в данном направлении, и вскоре мы увидим множество интересных бизнес-моделей, ориентированных на удовлетворение потребностей клиента здесь и сейчас. Однако, пока мы все находимся на пути к светлому будущему, важно учитывать особенности работы в крупных инфраструктурных проектах и максимально вовлекать в работу над проектом всех участников на как можно более ранних этапах.

Информация и фото с https://algoritm.org/arch/arch.php?id=93&a=2259