|
Сегодня учет рабочего времени (УРВ) по праву можно назвать одной из наиболее востребованных функций СКУД. Системы контроля и управления доступом исторически развивались как системы безопасности, однако зачастую заказчик руководствуется не соображениями безопасности. Повышение уровня трудовой дисциплины – вот один из наиболее популярных мотивов внедрения СКУД. Сам факт наличия считывателей рядом с каждой дверью и необходимость использовать персональный идентификатор для прохода уже является сильнейшим дисциплинирующим фактором. Однако только отчеты УРВ могут предоставить наиболее полную информацию о нарушениях трудовой дисциплины.
Исходные данные
Простой неформатированный список входов и выходов каждого сотрудника, конечно, позволит сделать выводы об опозданиях, прогулах, уходах раньше времени и т. п. Однако при наличии достаточно большого количества персонала такой формат вывода информации практически неприменим ввиду ощутимых временных издержек, связанных с анализом этих данных. Поэтому, конечно, руководители отделов и предприятий, бухгалтеры, менеджеры по персоналу и прочие заинтересованные лица предпочитают использовать аналитические отчеты УРВ – такие, в которых информация представлена уже в обработанном виде. Общее отработанное время должно быть посчитано за каждый день и суммировано за выбранный период, специальный отчет по нарушениям рабочего расписания должен отображать только тех сотрудников, которые отклонялись от рабочего графика, и указывать величину этих отклонений и т. п.
Для построения подобного рода аналитических отчетов УРВ система контроля и управления доступом использует следующие исходные данные:
- фактические данные о проходах;
- расписания рабочего времени сотрудников;
- вносимые вручную поправки рабочего времени – командировки, больничные и т. п.;
- прочие параметры, такие как нештрафуемое отсутствие, допустимое опоздание и т. п.
Проблема и причины
Указанных выше данных достаточно для того, чтобы корректно рассчитать отработанное время и другие искомые показатели. При одном условии: все сотрудники всегда используют свой персональный идентификатор для всех входов и выходов. В противном случае мы обязательно столкнемся с определенными конфликтами.
Что делать, если у сотрудника есть событие входа утром, но нет выхода в конце рабочего дня? Он усердно работал и просто забыл приложить свою карту к считывателю при уходе домой или он покинул рабочее место уже спустя 5 минут после входа? А если наоборот – есть выход, но нет входа?
Как трактовать два события входа или два события выхода подряд? Где сотрудник провел время между этими событиями? Как обрабатывать подобные конфликты и что писать в отчете?
Рассмотрим наиболее типичные ситуации:
1. Отсутствие «входа» в начале рабочего дня.
Например, начало рабочего времени – 9.00. В системе зафиксирован «выход» в 10.00, затем «вход» в 10.05. Далее идут прочие события перемещения сотрудника по территории объекта. Период с 9.00 до 10.00 – период неопределенности для данного сотрудника. Разрешить неопределенность можно двумя способами.
Первый – добавить искусственный «вход» в 9.00. Этот метод – в пользу сотрудника. Период с 9.00 до 10.00 будет засчитан ему как отработанное время. Второй – изъять «выход» в 10.00. В таком случае рабочее время для данного сотрудника начнет считаться с 10.05 – времени первого достоверно зафиксированного события «входа» в течение рабочего дня.
2. Отсутствие «выхода» в конце рабочего дня.
Например, конец рабочего времени – 18.00. В системе зафиксирован «выход» в 16.55, затем вход в «17.00» – последнее событие в рамках рассматриваемого рабочего дня. Период с 17.00 до 18.00 – период неопределенности. Аналогично описанному выше примеру можно добавить либо искусственный «выход» в 18.00 (в пользу сотрудника), либо изъять не имеющий пары «вход» в 17.00 (не в пользу сотрудника).
3. Отсутствие строго парных событий «вход-выход».
Например, в системе зафиксирована последовательность: «вход» в 12.00, «вход» в 13.00, «выход» в 14.00, выход в «15.00». Периоды между одноименными событиями (с 12.00 до 13.00 и с 14.00 до 15.00) являются периодами неопределенности. Разрешить неопределенность можно, приняв одно из допущений относительно правил счета:
- истинными являются первый вход и последний выход в последовательности. В данном случае сотруднику будет засчитан интервал с 12.00 до 15.00. Его можно назвать временем вероятного присутствия;
- истинными являются последний вход и первый выход. В данном случае сотруднику будет засчитан интервал с 13.00 до 14.00, который можно назвать временем гарантированного присутствия.
Однозначно достоверные данные в отчете УРВ можно получить только при условии отсутствия описанных выше конфликтов. Тем не менее подобные ситуации неопределенности почти гарантированно будут возникать на каждом объекте. Поэтому задача разработчиков СКУД состоит в том, чтобы устранить подобные факты неопределенности и нормализовать исходные данные – принять некоторые допущения или дать возможность пользователю выбрать допущения, на основе которых будут строиться отчеты.
Вывод
В данной статье мы обозначили проблематику учета рабочего времени и продемонстрировали, что алгоритм расчета играет определяющую роль в построении отчетов УРВ.
Мы рассмотрели лишь небольшой фрагмент весьма обширного спектра вопросов построения аналитических отчетов УРВ. Порядок учета обеденного перерыва, ночных смен, поправок к рабочим расписаниям, учет нарушений и переработок – задачи, однозначного решения которых пока не существует.
Поэтому, внедряя систему контроля и управления доступом для управления трудовой дисциплиной, попытайтесь оценить, насколько алгоритмы расчета и допущения, принятые в ней разработчиками, соответствуют вашим задачам учета рабочего времени.
Мы рекомендуем для УРВ использовать Терминал учета рабочего времени «Sphinx E100»
|
