Подписка
МЕНЮ
Подписка

Ближайшие онлайн-мероприятия компании "Гротек" 23 июля. BPM/ECM-платформы для автоматизации бизнес-процессов 24 июля. Отечественные ИT-платформы и ПО для объектов КИИ 25 июля. Пожарная безопасность и минимизация ущерба от возгораний зданий 31 июля. Чат-боты и голосовые ассистенты для бизнеса   Регистрируйтесь и участвуйте!

СКУД для пользователя или для решения задач?

Сергей Лещев, 28/04/23

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

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

На потребительском рынке учет потребностей конечного пользователя стал реальным конкурентным преимуществом. Что же происходит во взаимоотношениях разработчика и клиента применительно к рынку безопасности?

Мы знаем немало примеров продуктов, которые, c одной стороны, прекрасно закрывают одни задачи, с другой – не уделяют должного внимания прочим факторам, что приводит к проблемам у конечного пользователя. Например:

  • Интерфейс ПО, базирующийся исключительно на "самых актуальных" подходах к визуальному исполнению, ориентированных, очевидно, не на использование в режиме 24/7, приводит зачастую к отторжению со стороны пользователя: это или слишком "пестрое" исполнение, отвлекающее от продуктивной работы, или, наоборот, излишне минималистичное, выполненное в монохроме.
  • Хорошее и функциональное оборудование, но недопроектированное с точки зрения промышленного дизайна может оказаться неудобным в обслуживании или вовсе неремонтопригодным.
  • Предусмотренный качественный функционал, но требующий слишком "большого количества кликов".

Импортозамещение. Российские СКУД >>

Пользователи систем безопасности и их запросы

  1. Администрация. Именно эти люди принимают решение о необходимости той или иной системы, затем решение о закупке или модернизации. Как правило, они формулируют потребности в виде бизнес-задач, а не конкретных технических решений. Их мнение не может не учитываться. Но курьез в том, что часто именно управленческая часть компании-заказчика не является пользователем системы.
  2. Отдел безопасности, если он есть. Данным специалистам важны технические моменты: то, как реализовано шифрование, как построена архитектура, которую придется настраивать и поддерживать.
  3. ИТ-отдел. Системы безопасности в последние годы, как правило, интегрированы в прочие ИТ-системы. Однако мнение данных специалистов учитывается уже не так хорошо. Вряд ли вы найдете системного администратора, довольного тем, что ему придется обслуживать оборудование на интерфейсе RS-485. ИТ-специалистам важно, чтобы система поддерживала существующие стандарты в кросс-отраслях – в инфраструктуре, в сертифицированном оборудовании.
  4. Бухгалтерия. Эта область развивается не так быстро, и в ней очень значим человеческий фактор, но при этом мало готовых разбираться в нововведениях технических специалистов. Известны случаи, когда внедряется система автоматизации, призванная облегчить, ускорить реализацию ряда бизнес-процессов. Но из-за того, что данные передаются не в том формате или не так подсчитаны, в итоге увеличивается количество ручного труда. Для успешного взаимодействия бухгалтерии и новой системы безопасности важно услышать и понять задачу клиента, при этом, возможно, решая ее не тем способом, который предлагает сотрудник бухгалтерии, а через понимание корня проблемы.
  5. Работа с отделом кадров во многом напоминает взаимодействие с бухгалтерией. СКУД, например, может быть одним из ключевых инструментов для данного отдела. Но для успешного внедрения важно понять все особенности компании, объекта, текущую работу бюро пропусков. К сожалению, на этом уровне нужные вопросы задаются достаточно редко. Многие проблемы и неучтенные моменты вскрываются уже на этапе обучения работе с новой системой.
  6. Сотрудники. Это именно те работники, которые ежедневно проходят через СКУД, пользуясь своими карточками, смартфонами или иными идентификаторами. Здесь нет и не может быть конкретных стандартов и советов, но есть ситуации, которые заставляют задуматься. Например, регулярные сбои в системе распознавания лиц "после праздников". Или важный имиджевый момент, если речь идет не только о работниках, но и о клиентах, где доступ на территорию становится бизнес-образующим фактором. Так, доступ в фитнес-клуб должен быть быстрым и удобным, кроме этого, используемое оборудование должно также стилистически вписываться в общий дизайн пространства.

Так ли важно учитывать мнение всех пользователей?

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

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

Точки компетенции

Возможное решение, которое возникает на основе рассмотренных вопросов, – это понимание точек компетенции. На стороне заказчика это могут быть люди, знающие, как устроен объект, какие есть процессы и где могут решить внутренние задачи. Эти сотрудники должны обладать определенными знаниями о том, как устроено оборудование и программное обеспечение у того или иного вендора. Такой же точкой компетенции выступает инсталлятор – его квалификация также должна охватывать обе стороны процесса. Точкой компетенции является вендор, оказывая определенные услуги по аудиту компании заказчика для подбора оптимальных решений. Заказчик же в этих взаимосвязанных процессах должен быть максимально открыт для предоставления необходимых данных.

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

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

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

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

Опубликовано в журнале "Системы безопасности" № 2/2023

Все статьи журнала "Системы безопасности"
доступны для скачивания в iMag >>

ОБЗОРЫ ПО БЕЗОПАСНОСТИ >>

Фото: teldata.pl

Темы:СКУДЖурнал "Системы безопасности" №2/2023
Статьи по той же темеСтатьи по той же теме

Хотите участвовать?

Выберите вариант!

 

КАЛЕНДАРЬ МЕРОПРИЯТИЙ
ПОСЕТИТЬ МЕРОПРИЯТИЯ
ВЫСТУПИТЬ НА КОНФЕРЕНЦИЯХ
СТАТЬ РЕКЛАМОДАТЕЛЕМ
Комментарии

More...