Опубликовано: 18 Декабря 2013

Системы контроля и управления доступом (СКУД)* сейчас достаточно широко применяются для упрощения процессов управления людскими потоками на предприятиях и, соответственно, для снижения затрат, связанных с этими процессами.
Внедрение СКУД в организации, естественно, не ограничивается техническими мероприятиями. Более того, без достаточно глубоко проработанной идеологии построения системы не стоит принимать технические решения.
Остановимся на основных этапах построения СКУД с точки зрения организационных мероприятий.
ОСОЗНАНИЕ И ОПИСАНИЕ ЗАДАЧИ
Прежде всего руководство компании должно осмыслить необходимость внедрения СКУД, проанализировать задачи, которые могут быть решены при использовании системы, оценить уровень затрат на внедрение и эксплуатацию и сопоставить эти затраты с предполагаемой выгодой. Такая предварительная оценка может служить основанием как для принятия принципиального решения о создании системы, так и для первоначальной выработки технических требований.
После принятия принципиального решения очень важно определить руководителя/координатора проекта и синхронизировать его понимание задачи с пониманием руководства. Впоследствии именно у этого человека будет «болеть голова» по поводу правильного воплощения идеи.
Следующий шаг – формальное описание задачи на основании проведенного анализа. Такое описание может представлять из себя короткий (на 2-3 страницы) документ, позволяющий потенциальному подрядчику оценить перспективы участия в проекте и подготовить черновое коммерческое предложение.
ПОИСК И ВЫБОР ПОДРЯДЧИКА
Часто при построении системы заказчик делает ключевую, на мой взгляд, ошибку, когда выбор идеологии и технической реализации выстраивается «от подрядчика». Другими словами, сначала на горизонте появляется «подрядчик» (чаще всего, выбранный субъективно), который предлагает и, в общем-то, навязывает идеологию и технические решения, исходя из своих возможностей и опыта. При этом такие решения далеко не всегда являются оптимальными в конкретной ситуации. Вообще, выбор подрядчика, на мой взгляд — это один из ключевых моментов построения любой технической системы, и СКУД здесь – не исключение. Чем более тщательным будет процесс выбора, тем меньше проблем возникнет в ходе реализации проекта, и тем больше он будет отвечать изначальным ожиданиям.
В государственных структурах такой выбор осуществляется при помощи тендера, что не всегда приводит к оптимальному результату, поскольку определяющим критерием является стоимость. Частные же компании могут себе позволить, не инициирую громоздкие тендерные процедуры, подобрать подрядчика в короткий срок и исходя из здравого смысла.
Процесс выбора подрядчика в простом случае может выглядеть следующим образом:

  • Выбор предполагаемых подрядчиков (3-5 компаний);
  • ознакомление предполагаемых подрядчиков с описанием задачи;
  • взаимодействие с подрядчиками (ознакомление с объектом, уточнение условий);
  • разработка подрядчиками коммерческих предложений;
  • анализ коммерческих предложений заказчиком;
  • принятие решения на основании комплексной оценки.

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

Некоторые критерии в таблице могут показаться несущественными, но я бы, все-таки, рекомендовал принять их во внимание, поскольку, например, по скорости реагирования на заявку можно сделать предположение о соблюдении сроков работ, а большой размер компании-подрядчика может гарантировать непрерывность работ при проблемах с монтажниками или быструю замену оказавшегося неисправным оборудования.
Применение подобной таблицы поможет формализовать принятие решения. В крупной компании, имеющей множество объектов, когда необходимость в принятии решений существует постоянно, целесообразно усилить степень формализации принятия решений, используя весовые коэффициенты по каждому критерию для принятия окончательного решения. Разумеется, российская действительность вносит свои коррективы в процесс выбора в сторону значительного увеличения доли субъективности, однако, если, все же, руководствоваться не желанием личного обогащения или удобства, а интересами компании, следует использовать в работе формализованные методы принятия решения.
КОРРЕКТИРОВКА И УТВЕРЖДЕНИЕ КОММЕРЧЕСКОГО ПРЕДЛОЖЕНИЯ. РАЗРАБОТКА ТЗ, ПОДПИСАНИЕ ДОГОВОРОВ
Окончательно определившись с исполнителем работ по внедрению СКУД, можно вплотную приступать к подробному взаимодействию с ним. Взаимодействие это начинается с детальной корректировки предварительно оговоренной схемы, уточнения концепции и конкретного оборудования. При обсуждении идеологии системы, опыт подрядчика может оказаться неоценимым, ведь далеко не всегда заказчик четко представляет, как будет функционировать система, с какими нюансами ему придется столкнуться в процессе эксплуатации. Поэтому важно на данном этапе получить от подрядчика максимально подробную информацию. Не последнюю роль в уточнении спецификации оборудования, количества и расположения точек доступа и, соответственно, перечня работ, играет финансовый вопрос. Минимизировать затраты можно не только путем уменьшения объемов оборудования и работ, но и за счет некоторого (некритичного) снижения качества или надежности оборудования. На этом же этапе проговариваются места размещения центрального, оконечного и вспомогательного оборудования. В моей практике был случай, когда характеристики закупаемого оборудования не были досконально изучены даже подрядчиком. Размещение контроллеров СКУД (на 8 точек каждый) было спроектировано на стенах офисных помещений под потолком. После доставки оборудования выяснилось, что размеры и масса этих контроллеров несколько отличаются от среднестатистических для такого рода оборудования. Контроллер производства уважаемой американской компании, сделанный по военным стандартам НАТО, представлял собой металлический ящик размером с системный блок компьютера и весом 15 кг. О размещении этих устройств в запланированных местах на гипсокартонных стенах не могло быть и речи. В результате пришлось срочно вносить корректировки в проект, что повлекло за собой дополнительные материальные и временные затраты. Короче говоря, чем подробней будет проработана система на данном этапе, тем меньше неприятностей ждет заказчика в процессе монтажа и ввода в эксплуатацию. Не менее важно уделить внимание документальному оформлению принятых решений. В процессе обсуждения может показаться, что сторонами достигнуто полное взаимопонимание и необходимость в подробном документировании принятых решений отсутствует. Однако, такая ситуация может доставить массу неприятностей, если досконально не зафиксировать все договоренности документально. Нет ничего более мучительного для заказчика, чем работать по формальному договору или вообще без него. Такие вещи обычно снижают общую первоначальную стоимость системы, но могут значительно увеличить ее уже в процессе монтажа. Как правило, все технические особенности проекта прописываются в ТЗ (Техническом Задании). Техническое Задание может быть как отдельно на проектирование, так и на систему в целом. Обычно ТЗ пишет исполнитель работ и согласовывает его с заказчиком в виде приложения к договору. Такая ситуация логична, поскольку подрядчик по определению профессионал в этом вопросе. Задача заказчика здесь – не поддаться соблазну формального изучения ТЗ и подробнейшим образом проверить документ на соответствие утвержденным решениям.
СОПРОВОЖДЕНИЕ МОНТАЖНЫХ И ПУСКОНАЛАДОЧНЫХ РАБОТ. РАЗРАБОТКА/КОРРЕКТИРОВКА ВНУТРЕННИХ НОРМАТИВНЫХ ДОКУМЕНТОВ ПО ПРОПУСКНОМУ РЕЖИМУ
После утверждения проекта, до начала монтажных работ, необходимо решить ряд организационных моментов:

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

Параллельно с сопровождением работ по монтажу оборудования, целесообразно начать разработку внутренних регламентирующих документов. Даже если в компании уже действует Регламент контрольно-пропускного режима, обязательно необходимо внести в него изменения, касающиеся СКУД.
Разработка Регламента пропускного режима в компании – тема для отдельной статьи, здесь лишь приведу краткий перечень вопросов, которые должны быть отражены в Регламенте:

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

ПУСКО-НАЛАДКА И ВВОД СИСТЕМЫ В ЭКСПЛУАТАЦИЮ.
После завершения монтажных работ подрядчик проводит пуско-наладку системы. На этом этапе необходимо плотно подключить к процессу сотрудников, которые будут непосредственно эксплуатировать систему. Сотрудники должны пройти теоретическое обучение, а также, усаствую в процессе пуско-наладки приобрести практические навыки.
На этом же этапе проводится ввод базы данных сотрудников в систему, назначение уровней доступа, привязка уровней доступа к конкретным сотрудникам, изготовление пропусков, выдача пропусков сотрудникам.
Ввод системы в эксплуатацию может проходить поэтапно, чтобы не вносить резких изменений в бизнес-процессы компании.
Резюмируя вышесказанное, можно утверждать, что наиболее заинтересованной стороной при введении СКУД на предприятии является заказчик, поэтому подробное участие заказчика во всех процессах разработки системы и плотное взаимодействие с подрядчиком необходимо для успешного внедрения СКУД.
* Реже встречается термин СКД (Система контроля доступа) — более корректный, на мой взгляд, поскольку слово control (англ.) предполагает контроль в широком значении, включая в себя как получение информации о происходящих процессах, так и возможность управления этими процессами.

Автор: Николай Дворецкий
Источник: Директор по безопасности — 2010