В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
Во-первых, концепцию и назначение системы на конкретном объекте. Всем известно, что главная задача СКУД – не пустить на объект тех, кого не нужно, а кого нужно – пропускать в строго отведенное время и туда, где ему необходимо быть для выполнения своей работы. Это программа-минимум. Но список задач и возможностей системы значительно шире.
Во-вторых, особенности участия заказчика в процессе разработки системы. Система, которая должна будет регулировать режим и все передвижения на объекте, заметно влияет на сложившиеся привычки и подходы к управлению, а значит, она может быть полезной только в том случае, если заказчик выступает полноправным соавтором концепции и подкрепляет работу системы всеми необходимыми оргмероприятиями и регламентами.
В-третьих, оценку системы как рабочего инструмента руководителя – с точки зрения экономической эффективности и повышения "прозрачности" предприятия.
Обычно эти вопросы мы решаем в рамках разработки модели защиты объекта, но в данном случае будем рассматривать ту часть, которая касается управления режимом. Начнем с концепции.
Как уже было сказано выше, основная задача СКУД – разграничение доступа по критерию "свой/чужой". На первый взгляд простая задача. Но если представить себе предприятие (например, НПЗ или аэропорт) со штатом в несколько тысяч сотрудников, производственными территориями, транспортным парком, несколькими десятками подрядных организаций, у которых есть свой транспорт, то установкой турникетов и шлагбаумов на КПП явно не обойтись. Задача раскладывается на целый ряд подготовительных этапов, по мере выполнения которых определяется граница достаточности системы – что на объекте нужно, а что нет.
Что это за этапы? Мы строим свою работу следующим образом.
Прежде всего следует определиться с основными параметрами режима доступа для разных категорий сотрудников, посетителей и транспорта. Для этого необходимо:
Следующий существенный момент – предусмотреть набор решений для минимизации человеческого фактора. Здесь мы имеем в виду не столько ошибочные действия операторов, сотрудников или посетителей (хотя и их тоже), сколько осознанное противодействие системе. Это один из наиболее острых вопросов, который зачастую остается без внимания. Вместе с этим очевидно, что система, не умеющая выявлять попытки саботажа, будет бесполезной. Например, как исключить ситуации, когда сотрудник строительной подрядной организации завода был уволен за появление на объекте в нетрезвом виде, а через некоторое время вновь устраивается на работу в другую организацию, тоже выполняющую подряд на этом заводе. Или, например, ситуацию, когда сотрудник фиксирует картой свой выход с предприятия, но остается на объекте (а по данным системы, он вышел). Таких узких моментов очень много, и они в действительности определяют эффективность и работоспособность СКУД. Поэтому проектировать систему правильнее в жестко заданных рамках, исходя из того, что угрозой может выступить любой неблагонадежный сотрудник, включая охранника или сотрудника, обладающего доступом к критическим элементам. В нашей практике этот вопрос прорабатывается особенно тщательно, поскольку проектные риски заказчика здесь наиболее высоки.
Итак, результатом работы по двум первым пунктам является концепция СКУД в контексте защиты режима. На этом можно было бы закончить список. Он уже предполагает довольно большой набор проектных и технических решений. Но есть и другая сторона вопроса – управленческая, где СКУД выступает регулятором производственных процессов, трудовой дисциплины, отгрузки и транспортировки продукции предприятия. Поэтому в нашем перечне появляется еще один крупный раздел, который представляет своего рода программу-максимум для СКУД крупного объекта. Это СКУД в системе управления предприятием.
С точки зрения руководства, СКУД выступает источником большого массива данных по вопросам трудовой дисциплины, а также может применяться для регулирования и контроля процессов отгрузки и транспортировки продукции. В последнее время эти возможности становятся все более востребованными.
Функционал учета рабочего времени и отчетности по трудовой дисциплине понятен. Эти возможности активно используются заказчиками не первый год. Что касается отгрузки и транспортировки продукции, есть над чем задуматься. С одной стороны, в СКУД ведется учет автотранспорта, включая номер, фото, параметры а/м, права доступа, рабочие графики водителей, маршруты и т.д. С другой – на любом крупном заводе есть АСУ, в которой ведется, помимо прочего, контроль отгрузок продукции. Процесс весьма ответственный.
Обеспечивая интеграцию СКУД с АСУ в части управления отгрузками, мы получаем систему маршрутирования транспорта и контроля отгрузок. Весь процесс – от появления автомобиля на территории объекта до выезда с него – становится для руководителя службы безопасности и других служб прозрачным и контролируемым.
Система может дополнительно снимать показатели с весовой (где определяется вес до и после погрузки) или с тепловизионной системы, определяющей границу налива (если речь идет о топливе и автоцистернах). Таким образом, можно полностью исключить возможность любых махинаций с вывозом неучтенной продукции или ввозом сырья в меньших количествах, чем это зафиксировано документально. Мы недавно завершили серию подобных проектов на нескольких крупных НПЗ и можем сказать, что экономическая целесообразность здесь очевидна.
Остается последний элемент, завершающий концепцию СКУД. Это проектирование информационных потоков комплекса и алгоритмов обработки событий. Особое внимание здесь необходимо уделить вопросам защищенности данных в системе – никакая информация не должна меняться в системе без наличия на то соответствующих прав, и без персонализации выполненных действий.
Второй момент – вариабельность алгоритмов обработки событий. Например, на объекте в режимной зоне человек перемещается с одного участка на другой. Должна ли система проверить, откуда этот человек тут взялся, и, если до настоящего момента его карта доступа не появлялась ни на одном КПП или точке доступа, подать сигнал тревоги? Ведь получается, он возник на объекте из ниоткуда. А это тревожный признак. И таких ситуаций, которые необходимо закладывать в систему на уровне алгоритмов обработки событий, огромное количество. На сегодняшний день эти вопросы хорошо проработаны в авиации, где автоматизированное управление уровнями безопасности объекта на уровне ССОИ и СКУД является требованием нормативных документов.
Третий момент – это интеграционные возможности СКУД. Поскольку система является самым информативным источником данных (самым емким остается видеонаблюдение), она должна уметь грамотно обмениваться информацией с другими системами. Прежде всего с АСУ предприятия, где на основании данных СКУД принимается широкий ряд управленческих решений.
Таков в целом процесс разработки концепции СКУД крупного предприятия. Остаются два существенных вопроса, о которых было заявлено в начале статьи. Первый – особенности участия заказчика в процессе разработки системы. Второй – оценка системы с точки зрения экономической эффективности.
СКУД – пожалуй, наиболее емкая система с точки зрения участия заказчика в разработке. В отличие от остальных систем безопасности СКУД является не только системой безопасности. А потому крайне важна концепция системы и политическая воля руководства на то, чтобы с помощью этой системы решать определенные задачи. Прежде всего, задачу формирования и поддержания единой политики безопасности и режима. Если это принимается как основа, тогда уже можно конкретизировать задачи и подбирать технологии. Но идеология первична и вовлеченность заказчика в ее разработку – 100%-ная, с привлечением представителей разных служб.
Другой важный момент, связанный с участием заказчика, – это поддержка внедрения системы. Она заключается, во-первых, в целенаправленном информировании сотрудников о правилах соблюдения режима. Во-вторых, в регулярной работе с данными системы и принятии решений с использованием этих данных. Только таким образом система сможет "вжиться" в рабочие процессы и стать инструментом руководства, а не формально присутствующим на объекте набором оборудования.
Более того, от качества участия заказчика в разработке концепции и качества организационной поддержки внедрения зависит и эффективность всего проекта (если, конечно, разработчик компетентен). На наш взгляд, критериями оценки СКУД должны выступать два показателя: деньги, не ушедшие в песок благодаря СКУД (исключение хищений, аварий, простоев из-за нештатных ситуаций), и деньги, заработанные благодаря СКУД (оптимизация рабочих графиков, повышение трудовой дисциплины и эффективности использования транспортного парка, повышение скорости реагирования).
Общим фоном для этой оценки является заметное сокращение "пожарных ситуаций", когда "все случилось и надо что-то делать". Основная часть работы службы безопасности уже фокусируется на предупреждении возможностей нарушения тех или иных правил. При этом инструментарий СКУД позволяет быть готовыми к любому развитию событий и реагировать быстро и точно.
Таковы кратко основные нетехнические аспекты проектирования СКУД. Это далеко не все вопросы, которые следовало бы упомянуть в рамках этой темы. На многих из них хотелось бы остановиться подробнее и дополнить примерами из практики. Особенно показательны примеры с объектов ТЭК и гражданской авиации, где сочетаются высокие требования к защищенности и невозможность полностью закрыть объект от внешнего мира.
Что касается конкретных технических решений, при хорошей концепции этот вопрос решается автоматически: "железо" подбирается под конкретные задачи, софт – под верхний уровень управления. И то и другое желательно выбирать не "впритык", а "на вырост", обращая особое внимание на стоимость владения, интегрируемость, расширяемость и надежность решения.
Какие выводы мы можем сделать?
Во-первых, масштаб СКУД как инструмента управления режимом значительно вырос. Сегодня этот класс систем является основным поставщиком информации (среди систем безопасности) для принятия многих существенных управленческих решений. А это означает, что будут меняться потребности и подходы к проектированию.
Во-вторых, СКУД не бывает эффективной без активного участия заказчика в разработке концепции и при поддержке проекта внедрения системы, потому что дело касается самого режима, а не только наблюдения за режимом.
В-третьих, грамотная концепция системы, разработанная на начальной стадии, дает 80% результата всего проекта (по правилу Парето), позволяет минимизировать проектные и финансовые риски заказчика, а также обеспечивает точное соответствие будущей системы потребностям предприятия. Это подтверждается нашим опытом и опытом наших уважаемых заказчиков.
Надеемся, что рекомендации данной статьи окажутся полезными и для вас.
Опубликовано: Каталог "СКУД. Антитерроризм"-2012
Посещений: 8952
Автор
| |||
В рубрику "Системы контроля и управления доступом (СКУД)" | К списку рубрик | К списку авторов | К списку публикаций
