Журнал ТЗ № 6 2014 | Учет рабочего времени: если нет однозначного решения
  бюро находок  
  Где искать        
наши издания
наши анонсы






2014
№ 6
статьи



Журнал ТЗ № 6 2014



Раздел: КОНТРОЛЬ ДОСТУПА
Тема:
Автор: Антон СЕРДЮКОВ, начальник учебного центра Parsec

Учет рабочего времени: если нет однозначного решения

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

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


Проблема и причины
Указанных выше данных достаточно для того, чтобы корректно рассчитать отработанное время и другие искомые показатели. При одном условии: все сотрудники всегда используют свой персональный идентификатор для всех входов и выходов. В противном случае мы обязательно столкнемся с определенными конфликтами.
Что делать, если у сотрудника есть событие входа утром, но нет выхода в конце рабочего дня? Он усердно работал и просто забыл приложить свою карту к считывателю при уходе домой или он покинул рабочее место уже спустя 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, который можно назвать временем гарантированного присутствия.
Однозначно достоверные данные в отчете УРВ можно получить только при условии отсутствия описанных выше конфликтов. Тем не менее подобные ситуации неопределенности почти гарантированно будут возникать на каждом объекте. Поэтому задача разработчиков СКУД состоит в том, чтобы устранить подобные факты неопределенности и нормализовать исходные данные – принять некоторые допущения или дать возможность пользователю выбрать допущения, на основе которых будут строиться отчеты.

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


Внимание! Копирование материалов, размещенных на данном сайте допускается только со ссылкой на ресурс http://www.tzmagazine.ru

Рады сообщить нашим читателям, что теперь нашем сайте работает модуль обратной связи. Нам важна ваша оценка наших публикаций! Также вы можете задавать свои вопросы.Наши авторы обязательно ответят на них.
Ждем ваших оценок, вопросов и комментариев!
Добавить комментарий или задать вопрос

Правила комментирования статей

Версия для печати

Средняя оценка этой статьи: 5  (голосов: 1)
Ваша оценка:

назад
|

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



Новинка от компании IDIS: 5Мп IP-видеокамера DC-T3533HRX
Тенденции развития индустрии IP-видеонаблюдения демонстрируют погоню производителей за увеличением разрешающей способности видеокамер. При этом часто оказывается так, что озвучиваемые цифры в 4, 9, 12 и даже 20 мегапикселей оказываются несопоставимыми с физическими размерами сенсоров, используемых в этих камерах. Поэтому подобные разрешения реализуются лишь на уровне соответствующих цифр в настройках камеры и не приводят к какому-либо улучшению изображения.



IBM меняет представление о передаче и хранении видео. Впервые на All-over-IP 2017!
Сравните ваш взгляд на интеллектуальное видеонаблюдение с мнением руководителей корпорации IBM на 10-м форуме All-over-IP 2017.



Реклама
Подписка на новости
Имя
E-mail
Анти-спам код
Copyright © 2008 —2017 «Технологии защиты».