Программное обеспечение настроили по быстрому. Создали три группы доступа: «директора», «отделы», «охрана». Решили, что этого хватит. Не хватило. В отделе финансов 12 человек, и только трое должны были иметь доступ в архив. Пятерым нужен был доступ в серверную, а четверым — нет. Все попали в одну группу «отделы». Получили одинаковые права. Через неделю руководитель финансов обнаружил, что младший бухгалтер заходил в серверную. «Я просто приложил карту, и дверь открылась». Система не знала разницы между сотрудниками.
Самой критичной ошибкой стала интеграция с учетом рабочего времени. Мы подключили СКУД к программе, которая считает зарплату. Данные передавались по простому протоколу, без проверки.
> Если человек заходил в 8:55, а в системе учета стояло 9:00, записывалось опоздание.
> Если выходил в 18:03, а должен был в 18:00, регистрировался переработок в три минуты.
Бухгалтерия начала получать отчеты, где половина штата опаздывала каждый день. Хотя реально они приходили вовремя. Данные о проходах передавались с задержкой в несколько секунд, и это съедало время. Начались массовые конфликты. Люди получали выговоры за опоздания, которых не было. Система превратилась в генератор скандалов.
Обучение администраторов СКУД почему инструктаж за 15 минут не работает
После сдачи проекта мы провели инструктаж. Два часа теории, 15 минут практики. Показали, как добавить карту, как удалить, как сделать отчет. Администраторы кивали. Через три дня один из них позвонил в панике. «Уволился сотрудник, я удалил его карту, а он все еще проходит». Оказалось, он удалил карту из базы, но не синхронизировал изменения с контроллерами. Карта продолжала работать. Это базовая операция, которую нужно делать через три клика. Никто не рассказал, что синхронизация отдельная команда. Мы забыли упомянуть. Администратор думал, что удаление из базы — это автоматически удаление из всей системы.
Вторая проблема — отчеты. Мы показали стандартный шаблон: «Список проходов за день». Администраторы не знали, как отфильтровать по отделу, по времени, по статусу прохода. Когда директор попросил статистику, кто из сотрудников работает после 20:00, администратор экспортировал 50 тысяч строк и начал вручную искать нужные записи. Потратил три дня. Система могла сделать это за три секунды. Никто не показал, как.
Эксплуатация СКУД без поддержки когда система становится врагом
После сдачи проекта мы передали документацию и ушли. Техническая поддержка не предусматривалась. Через две недели вышло обновление ПО. Оно закрывало уязвимость, но ломало интеграцию с учетом рабочего времени. Заказчик не обновился, потому что боялся, что все сломается. Через месяц уязвимость использовали, но не хакеры. Обычный сотрудник нашел в интернете, как склонировать карту при помощи смартфона. Сделал это для прикола. Зашел на территорию ночью, когда охраны не было. Система зафиксировала проход, но как «антипасс». Потому что считыватель сработал дважды: вход и выход через одну секунду. В логах это выглядело как ошибка. Никто не обратил внимание.
Через три месяца сломался один из считывателей. Заказчик позвонил. Мы сказали, что гарантия истекла, ремонт платный. Они решили сами купить новый считыватель в интернет-магазине. Подключили. Он не работал. Потому что несовместим по разрядности данных. Старый работал по Wiegand 26 бит, новый — 34. Контроллер не понимал новый формат. Пришлось вызывать нас. Диагностика стоила дороже, чем сам считыватель.
Почему СКУД превращается в источник конфликтов между сотрудниками
Система начала работать не как инструмент безопасности, а как генератор напряженности. Охрана не доверяла показаниям, потому что были ложные срабатывания. Администраторы боялись нажимать кнопки. Сотрудники злились, потому что им приходилось по три раза прикладывать карту. Руководство не верило отчетам о рабочем времени. Каждый день кто-то звонил и жаловался. Система вместо того, чтобы решать проблемы, создавала новые.
Через пять месяцев после запуска заказчик принял решение. Демонтировать все и искать нового подрядчика. Они потратили 1,2 млн на установку. Плюс 800 тысяч на переделки. Плюс время, которое потеряли на разбор конфликтов. Общие затраты превысили 2,5 млн. Система проработала меньше года.
Как внедрить СКУД без провала проекта
СКУД не просто набор турникетов и карточек. Это сложный организм, где каждый компонент влияет на все остальные. Успех зависит от пяти факторов.
- Тщательного обследования с учетом реального поведения людей и пожарных норм.
- Проектирования с запасом надежности, а не экономии на контроллерах и ИБП.
- Монтажа специалистами, которые понимают, что металл гасит сигнал, а кабель нельзя класть рядом с силовой линией.
- Настройки ПО под бизнес-процессы с детальным обучением администраторов.
- Надежной техподдержки, которая не бросает заказчика одного с проблемами.
#СКУД #безопасность #офиснаябезопасность #управлениедоступом #инфобез #кибербезопасность #информационнаябезопасность #физическаябезопасность #ИТвбизнесе #техническаяподдержка