Предприятию недостаточно знать, что сотруднику разрешён доступ в здание. Для кадрового и административного учёта нужны другие данные: когда человек фактически появился на объекте, во сколько покинул его, было ли опоздание, ранний уход или отклонение от установленного графика.
Учёт рабочего времени через СКУД строится на данных о проходах сотрудников: каждый проход через контролируемую точку создаёт событие с идентификатором, временем и направлением доступа. Но между записью «Иванов — вход — 08:47» и готовым табелем есть ещё несколько этапов обработки.
Именно поэтому СКУД и система учёта рабочего времени — не одно и то же.
Результат зависит от того, какие точки доступа контролируются, как фиксируются вход и выход, какое программное обеспечение используется и какие правила рабочего времени в нём настроены.
Как СКУД фиксирует приход и уход сотрудника
В основе системы находится не расчёт часов, а последовательная регистрация событий.
Типовая цепочка выглядит так:
Сотрудник → карта / лицо / отпечаток → считыватель или терминал → контроллер → разрешение доступа → событие в системе → ПО → обработка → отчёт.
На первом этапе система должна идентифицировать человека. Сотрудник предъявляет карту, вводит PIN-код, прикладывает палец или проходит идентификацию по лицу — в зависимости от используемого оборудования.
Затем СКУД проверяет права доступа. Например, сотруднику может быть разрешён вход через проходную с 07:00 до 20:00, но запрещён доступ в серверную. Идентификация пользователя ещё не означает разрешение прохода: решение принимается с учётом назначенных ему прав и настроенных правил системы.
После разрешённого или запрещённого доступа формируется событие. Обычно оно содержит пользователя или идентификатор, точку доступа, дату, время, тип события и другие предусмотренные конкретной системой параметры.
И только после этого начинается собственно учёт рабочего времени. Программное обеспечение должно определить, какое значение имеет конкретное событие для рабочего графика сотрудника.
СКУД регистрирует события доступа, а учёт рабочего времени интерпретирует эти события по заданным правилам.
Из проходов в табель: где появляется учёт рабочего времени
Предположим, система зарегистрировала:
Иванов — вход — 08:47.
Это достоверное событие доступа, но само по себе оно ещё не отвечает на вопрос, опоздал Иванов или пришёл вовремя.
Если его смена начинается в 09:00 — опоздания нет. Если в 08:30 — ситуация уже другая. Если сотрудник работает по плавающему графику, правила расчёта могут быть совсем иными.
Для получения рабочего времени программному обеспечению могут понадобиться:
- назначенный сотруднику график;
- время начала и окончания смены;
- допустимые интервалы регистрации прихода и ухода;
- правила обработки перерывов;
- календарь рабочих, выходных и праздничных дней;
- правила для ночных смен;
- обработка смен, переходящих через полночь;
- данные об отсутствии, отпуске или командировке;
- правила определения первого входа и последнего выхода.
Поэтому журнал событий СКУД и табель рабочего времени — разные сущности.
Журнал отвечает на вопрос: «Какие события зарегистрировала система?»
Табель должен отвечать уже на другой вопрос: «Как эти события интерпретируются относительно рабочего графика сотрудника?»
Именно на этом уровне появляются расчёт опозданий, ранних уходов, фактически отработанного времени и другие показатели.
Конкретные возможности зависят от используемого программного обеспечения, поэтому наличие журнала проходов ещё не означает наличие полноценного модуля учёта рабочего времени.
Карта, лицо или отпечаток: влияет ли способ идентификации на учёт времени
Для расчёта рабочего времени принципиально не столько то, насколько «современен» идентификатор, сколько насколько надёжно зарегистрированное событие связано с конкретным сотрудником.
| Способ идентификации | Что фиксирует система | Основной нюанс |
|---|---|---|
| RFID-карта | Предъявление назначенной сотруднику карты | Карту можно передать другому человеку |
| PIN-код | Ввод назначенного кода | Код можно сообщить другому сотруднику |
| Отпечаток пальца | Биометрическую идентификацию | Требуется совместимое оборудование и корректная регистрация шаблонов |
| Распознавание лица | Биометрическую идентификацию по лицу | Результат зависит от оборудования, условий эксплуатации и настроек |
Карточная система вполне подходит для учёта рабочего времени, особенно если задача не требует повышенной защиты от передачи идентификатора. Но событие предъявления карты подтверждает прежде всего использование конкретного идентификатора, а не биометрическую личность его владельца.
Биометрия позволяет сильнее связать идентификацию с конкретным человеком. Однако считать её абсолютной гарантией достоверности тоже неправильно: качество результата зависит от используемого терминала, алгоритмов, настроек и условий эксплуатации.
Поэтому способ идентификации выбирают исходя из требуемого уровня достоверности, режима объекта и возможных сценариев нарушений.
Дверь со считывателем или турникет
Здесь появляется ещё одна важная инженерная проблема: событие идентификации и физический проход человека — не всегда одно и то же.
Рассмотрим обычную офисную дверь. Сотрудник прикладывает карту, СКУД разрешает доступ и разблокирует электромагнитный замок. Следом за ним через открытую дверь может пройти коллега, не предъявляя собственный идентификатор.
Для контроля доступа это уже нежелательный сценарий. Для учёта рабочего времени он создаёт дополнительную проблему: второй сотрудник физически находится внутри здания, но соответствующего события входа система не получила.
В небольшом офисе такой уровень контроля может быть приемлемым. На складе, производственном объекте или предприятии с большим потоком сотрудников требования к достоверности обычно выше.
Турникет физически организует поток иначе: после разрешения доступа он пропускает человека через контролируемый проход. Поэтому на проходных предприятий турникеты часто позволяют получить более однозначную последовательность событий входа и выхода.
Но сам по себе турникет проблему не решает. Нужно правильно организовать направления прохода, считыватели, ограждения, аварийный выход, маршруты персонала и остальные точки, через которые сотрудники могут попасть на территорию или покинуть её.
Если задача предполагает полноценную проходную, отдельно необходимо прорабатывать организацию проходной с турникетом, а не просто добавлять турникет к существующей СКУД.
Что происходит, если сотрудник вошёл, но не зарегистрировал выход
Идеальная последовательность выглядит просто:
08:47 — вход
12:31 — выход
13:18 — вход
18:06 — выход
На реальном объекте данные часто оказываются сложнее.
Сотрудник может пройти вслед за коллегой, забыть карту, воспользоваться другой дверью или покинуть территорию через выход, на котором идентификация вообще не предусмотрена. Возможен временный отказ оборудования или связи. Человек также может остаться на территории после окончания своей смены, хотя это время не обязательно является рабочим.
Появляется неоднозначность: если система получила вход в 08:47, но не получила выхода, нельзя просто считать сотрудника работающим до полуночи.
Поэтому при проектировании необходимо определить, какие именно события считаются достоверными для расчёта рабочего времени.
Для более строгого учёта вход и выход желательно контролировать в обоих направлениях. Если используются несколько дверей или проходных, события со всех релевантных точек должны попадать в общую систему.
Программное обеспечение также должно предусматривать обработку исключений. Конкретные возможности различаются: где-то оператор может корректировать запись вручную, где-то предусмотрены отчёты об аномалиях, а где-то функциональность учёта рабочего времени минимальна.
Как учитывать смены, опоздания и работу через полночь
Для офиса с графиком 09:00–18:00 логика относительно проста. Назначается рабочий период, определяется допустимое время прихода и ухода, после чего события сотрудников сопоставляются с этим графиком.
На производстве задача сложнее.
Первая смена: 08:00–20:00.
Вторая смена: 20:00–08:00 следующего дня.
Событие выхода в 08:03 во вторник в таком случае должно относиться к смене, начавшейся ещё в понедельник. Простое группирование событий по календарным суткам даст неправильный результат.
Ещё сложнее ситуация с несколькими подразделениями. Администрация может работать 09:00–18:00, склад — посменно, служба безопасности — по собственному графику, а отдельные сотрудники — по индивидуальному или плавающему расписанию.
Поэтому до выбора программного обеспечения необходимо описать реальные графики предприятия, включая ночные смены, переход через полночь, выходные дни и исключения.
Не каждая СКУД умеет выполнять такой расчёт. Наличие контроллера, журнала событий и даже отчёта о проходах ещё не означает наличие полноценного модуля Time & Attendance.
СКУД и 1С: как передаются данные рабочего времени
Здесь полезно разделить задачи двух систем.
СКУД собирает фактические события → специализированное ПО интерпретирует их → полученные данные при необходимости передаются в кадровую или учётную систему.
Универсальной схемы «подключить СКУД к 1С» не существует.
В зависимости от используемых продуктов обмен может выполняться через готовый интеграционный модуль, API, SDK, экспорт и импорт файлов либо другой механизм, предусмотренный разработчиками систем.
Поэтому вопрос интеграции нужно ставить конкретно:
какая СКУД + какое ПО СКУД + какая конфигурация и версия 1С + какие именно данные требуется передавать.
Нельзя исходить из предположения, что любой контроллер или терминал автоматически интегрируется с любой конфигурацией 1С.
Несколько проходных и филиалов
На объекте с одним входом последовательность событий относительно легко контролировать.
На крупном предприятии сотрудник может утром войти через центральную проходную, днём перейти в другое здание, а вечером выйти через вторую проходную. Дополнительно могут существовать производственные зоны со своими точками доступа.
Если каждая точка работает изолированно, интерпретация событий становится сложнее.
Для корректного централизованного учёта необходимо обеспечить единую идентификацию сотрудников и сбор событий с релевантных точек доступа. Система должна понимать, что один и тот же идентификатор на первой и второй проходной относится к одному сотруднику.
Для филиальной структуры дополнительно возникает вопрос архитектуры: где располагается сервер, как филиалы передают события, что происходит при потере связи и каким образом данные после восстановления соединения попадают в общую систему.
Поддержка централизованной или распределённой архитектуры зависит от конкретной платформы, поэтому этот параметр необходимо проверять до выбора оборудования и программного обеспечения.
Типовая структура системы учёта рабочего времени через СКУД
Идентификатор связывает событие с сотрудником. Считыватель или терминал получает идентификационные данные. Контроллер принимает решение о доступе и регистрирует соответствующее событие либо участвует в его формировании — в зависимости от архитектуры оборудования.
Сетевая инфраструктура обеспечивает обмен с сервером. ПО централизует события и, если имеет соответствующий функционал, применяет к ним графики и правила учёта рабочего времени.
На выходе предприятие получает уже не просто список проходов, а отчётные данные, которые могут использоваться HR, службой безопасности, администрацией или передаваться в другую информационную систему.
Что подготовить перед проектированием
Основная работа начинается не с выбора считывателя или контроллера. Сначала нужно описать процессы предприятия.
| Что нужно определить | Почему это важно |
|---|---|
| Количество сотрудников | Влияет на ёмкость и архитектуру системы |
| Количество входов и выходов | Определяет число контролируемых точек |
| Количество зданий | Влияет на сеть, серверную и распределённую архитектуру |
| Рабочие графики | Определяют правила расчёта времени |
| Ночные смены | Требуют корректной обработки перехода через сутки |
| Способ идентификации | Определяет достоверность привязки события к сотруднику |
| Необходимость турникетов | Зависит от требуемого контроля фактического прохода |
| Учёт посетителей | Может потребовать отдельного процесса регистрации |
| Требования к учёту времени | Нужно определить, какие отчёты и отклонения действительно нужны |
| Интеграция с 1С | Требует проверки совместимости конкретных программных продуктов |
| Существующая СКУД | Часть инфраструктуры иногда можно использовать повторно |
| Резервное питание | Определяет работу системы при отключении электроснабжения |
| Сетевая инфраструктура | Необходима для связи контроллеров, терминалов и серверов |
Дополнительно полезно заранее нарисовать схему объекта и отметить все реальные маршруты сотрудников. Часто именно здесь обнаруживается, что формально «одна проходная» фактически дополняется служебным входом, воротами склада или дверью между корпусами.
После этого уже можно определить количество точек доступа, способы идентификации, требования к контроллерам, серверу, программному обеспечению и интеграциям.
Такой подход позволяет проектировать систему контроля доступа под задачи предприятия не только вокруг открытия дверей, но и вокруг качества данных, которые бизнес собирается использовать дальше.
Когда СКУД действительно подходит для учёта рабочего времени
Использование СКУД для учёта рабочего времени особенно логично там, где сотрудники и так проходят через контролируемые точки доступа. В этом случае предприятие получает события прихода и ухода без отдельной процедуры регистрации рабочего дня.
Но достоверность результата определяется всей цепочкой: идентификация → физический проход → событие → сбор данных → рабочий график → правила обработки → отчёт.
Если часть этой цепочки не контролируется, автоматизация может создать очень аккуратный отчёт на основе неаккуратных исходных данных.
Поэтому при проектировании нужно сначала определить, какие события предприятие хочет получать и как они должны интерпретироваться, а уже затем выбирать оборудование и программное обеспечение.
Для предварительного расчёта достаточно подготовить количество сотрудников и точек прохода, схему объекта, рабочие графики, требования к идентификации и учёту времени, а также указать необходимость интеграции с 1С или другими системами.
Специалисты «Авантаж Маркет» могут на основании этих данных подобрать архитектуру СКУД и оборудования под конкретный объект с реализацией по Казахстану.
Учёт рабочего времени через СКУД: ответы на частые вопросы
Иногда да. Необходимо проверить, какие события регистрирует существующее оборудование, контролируются ли вход и выход сотрудников и поддерживает ли используемое программное обеспечение функции учёта рабочего времени либо передачу данных в другую систему.
Не обязательно. В некоторых системах для регистрации рабочего времени можно использовать существующие точки контроля доступа. Возможность зависит от оборудования, программного обеспечения и требуемой схемы учёта. Само наличие считывателя и журнала проходов ещё не означает наличие полноценного модуля учёта рабочего времени.
Да, если выходы и последующие входы регистрируются системой, а программное обеспечение позволяет корректно интерпретировать эти события. При настройке необходимо определить, какие выходы считаются перерывами и каким образом они должны влиять на расчёт фактически отработанного времени.
Для таких ситуаций необходимо заранее определить регламент обработки исключений. В зависимости от возможностей конкретной системы это может быть временный идентификатор, ручная корректировка события или другой предусмотренный программным обеспечением механизм. Без корректного события входа или выхода автоматически рассчитанное рабочее время может оказаться недостоверным.
Да, если такая функциональность предусмотрена выбранной системой. Для посетителей обычно требуется отдельная логика регистрации, выдачи временных идентификаторов, назначения разрешённых зон и срока действия доступа. Эти события не следует автоматически учитывать по тем же правилам, которые применяются к рабочему времени постоянных сотрудников.
Это зависит от архитектуры конкретной СКУД. Локальные контроллеры могут выполнять основные функции доступа без подключения к интернету, однако обмен с удалённым сервером, филиалами или облачной платформой требует соответствующего канала связи. Также необходимо заранее проверить, сохраняются ли события локально при потере связи и как они передаются на сервер после её восстановления.
