Автоматизированное сравнение данных полученных со СКУД с табелем и графиком рабочего времени в ТОО «Степногорский горно-химический комбинат»

Разработка автоматизированной системы для службы безопасности предприятия, позволяющей в автоматическом режиме сравнивать данные СКУД с табелями и графиками рабочего времени

   Успешная реализация проекта по автоматизации продаж корпоративного питания в столовых предприятия горнодобывающий промышленности ТОО «Степногорский горно-химический комбинат» в городе Степногорск, Казахстан, явилась отправной точкой для развития дальнейших плодотворных отношений между нашими компаниями. Следующим (и, надеемся, не последним) стал проект по анализу данных о посещаемости сотрудников.

Как работали процессы идентификации посещаемости сотрудников до автоматизации?

Чтобы занять утром рабочее кресло в офисе, встать у станка или сесть за рычаги горнодобывающей машины, сотруднику горно-химического комбината необходимо себя успешно аутентифицировать в корпоративной системе контроля доступа (далее сокращённо СКУД). А что во всех организациях, где внедрена такая система, делает СКУД? Она просто отмечает, кто когда пришёл и кто когда ушёл. Казалось бы, данные о посещаемости работников уже есть, они хранятся в базе данных СКУД, но что с ними делать дальше? Как их анализировать? В большинстве случаев компания, в которой внедрена система контроля доступа, просто не может сопоставить эти данные с графиками, табелями рабочего времени и прочими данными из «1С: ERP Управление предприятием 2» или «1С: Зарплата и Управление персоналом 8». Отчёты, которые предоставляет любая СКУД, страдают полным отсутствием наглядности, требуют дополнительного экспорта в Excel, дальнейшей ручной обработки и анализа.

Проблемы сравнения данных, полученных с разных источников: СКУД, график, табель. 

Могут возникнуть вопросы: зачем анализировать данные о посещаемости, полученные со СКУД и сопоставлять их с табелями и рабочими графиками? Как автоматически анализировать данные из СКУД ?

ловить прогульщика

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

Итак, в компании существует несколько источников этой информации:

  1. СКУД. Кто когда пришёл и кто когда ушёл. Причём в данном случае для сопоставления данных с другими программами нас интересовали только данные «кто когда пришёл».
  2. Программы, в которых ведётся кадровый учёт, обычно это «1С: Зарплата и Управление персоналом 8» или «1С: ERP Управление предприятием 2». Отсюда нас интересовали статусы: «Работает», «На больничном», «По уходу за ребёнком», «В командировке» и так далее. Для анализа мы делали фильтр по всем статусам обоснованного отсутствия и оставляли для анализа только статусы, отмечающие, что сотрудник должен работать.
  3. График. Грубо говоря, это информация вида «по плану сотрудник должен сегодня выйти на работу». График также ведётся в программах кадрового учёта и может меняться, например, может меняться должность и так далее, причём нас интересовал график «на сейчас» (потому что по некоторым подразделениям график может заносится на будущие периоды).
  4. Табель учёта рабочего времени. Это информация факта выхода сотрудника на работу, формирующаяся в конце месяца, вида «сотрудник действительно выходил в эти дни, часы или смены». Табель также заполняется в программах кадрового учёта бухгалтером или кадровиком. Откуда бухгалтер или кадровик знает, что сотрудник действительно выходил в этот день? Эти данные ей передают начальники отделов, подразделений или цехов. Также важны точные сведения об отправках сотрудников в командировки, декретные и другие отпуска.

Задача стояла следующая: написать для службы безопасности предприятия систему, которая сопоставляет информацию из СКУД с табелями и графиками рабочего времени, находящихся в кадровой программе. Сформировать наглядные и понятные отчёты по отклонениям и несовпадениям между этими источниками, позволяющими выявить подозрительные ситуации. 

Какие ситуации бывают на крупных предприятиях? 

  • сотрудник обязан работать по графику, по данным СКУД не выходил на работу (не аутентифицировался), однако в поданном табеле он выходил (прогул, «прикрытый» начальником отдела?); 
  • сотрудник по графику не должен был выходить, но фактически он выходил на работу (не запланированные сверхурочные?);
  • сотрудник по графику должен был выйти, по факту он выходил на работу, однако в поданном табеле день или смена значится, как выходные (сверхурочные), что приводит к умышленной переплате, вопросы к начальнику отдела, участка или цеха).

доказывание прогула

Эту отчётность необходимо было сделать одновременно в ERP и в ЗУП. Программисты группы компаний «КомплектСофт» разработали блок аналитики, получающий на вход данные из четырёх вышеназванных источников и формирующий отчётность о несовпадениях между ними для ERP и ЗУП.

Схема работы:

поиск прогула

С какими сложностями мы столкнулись в процессе выполнения работ по анализу данных со СКУД

      Большая фактическая разница между конфигурациями ЗУП и ERP. На предприятии идёт плавный процесс перехода всех рабочих процессов с «1С: Зарплата и Управление персоналом 8» на «1С: ERP Управление предприятием 2», часть отделов работает в одной, а часть – в другой программе, поэтому специалистам пришлось и отчётность делать сразу в обе программы, и использовать обе программы в качестве источников информации.

Постановка задачи. Ни для кого не секрет, что чем точнее и полнее написано техническое задание, тем меньше вероятность встретить «подводные камни» в процессе реализации проекта. Мы чётко сформулировали в техническом задании совместно с интегратором со стороны Заказчика, что выемка данных из СКУД PERCO об аутентификациях должна происходить один раз в сутки, но ни Заказчик, ни мы не учли, что вообще-то на предприятии несколько разных смен с вариациями и происходит перенос часов в некоторых сменах с одних суток на другие сутки, а сотрудник может выходить на работу более одного раза за сутки. Попробуем понять, что получилось и с чем пришлось разбираться нашим специалистам.

На предприятии есть дневная смена (утренний выход на работу) и ночная смена (вечерний выход на работу). Причём время начала и конца смен по ряду причин может быть сдвинуто относительно друг друга в разных подразделениях, цехах, отделах (например, офисные работники с 9 до 18ч., а горнодобывающие подразделения начинают работать с 8 ч., есть стандартные 8-часовые смены, есть 12-часовые и есть 7-часовые смены). Сотрудник может пройти аутентификацию в СКУД утром или вечером, и при выемке данных из PERCO нужно различать, когда сотрудник вышел на работу, утром или вечером. Дополнительно ситуацию усложнял тот факт, что в графиках и в табелях нет чётного понятия «дневная смена» или «ночная смена». Можно «научить» блок анализа ориентироваться на данные СКУД – если сотрудник аутентифицировался до 9 или 10 утра – значит, он выходит на дневную смену, а если сотрудник аутентифицировался в промежутке между 18 и 21ч., — значит, он выходит в ночную смену. Однако в программах ЗУП и ERP нет «смен» вообще, зато есть «дневные» и «ночные» часы. Казалось бы, всё просто – раз дневные часы, значит это дневная смена; раз это ночные часы, значит это ночная смена. Если с дневными часами действительно просто, то с ночной сменой в графике это будет выглядеть следующим образом: в день выхода на смену в 21ч. будет написано, что он работает 4 часа, из них 3 ночных. На следующий день (после перехода суток через 0ч.) будет написано, что он работает 9 дневных часов, из них 6 ночных. Повторимся, факт того, что у работника есть дневные или ночные часы в эти сутки, не означает, что он работает только ночью или только днём. Происходит «деление», как бы переход из одних суток в другие. Этот нюанс не был учтён ни Заказчиком, ни нами на этапе постановки задачи и поначалу привёл к тому, что мы реализовали проект под однократную выборку данных из СКУД в течение рабочего дня, где логика очень упрощенно выглядела так: получаем данные «вышел/не вышел» и делаем проверку и сравнение с графиками и табелями: «есть дневные часы» = «должен работать», «нет дневных часов, но аутентифицировался» = «сверхурочные» (потому что пришёл на работу), и наоборот, «есть дневные часы» и «не аутентифицировался» = «прогул».

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

Как мы поменяли логику работы системы? Из-за того, что происходит перенос часов с сутки на сутки, а смена одна и та же, пришлось ввести дополнительную выборку данных из СКУД PERCO, дополнительную проверку и сравнение со всеми имеющимися на предприятии сменами, чтобы система могла разобрать все сложные ситуации вида: с 0ч. до 8ч. утра у сотрудника в табеле записано «явка 9 часов, ночных 6 часов» или «явка 8 часов». Пришлось учить систему понимать и сравнивать, «если явка 8 часов, когда пришёл сотрудник, сегодня или вчера?» или «если явка 9 часов, ночных 6 часов, когда пришёл сотрудник, сегодня или вчера?», для того чтобы исключить все ошибки вида «не аутентифицировался» = «прогул», зато получал срабатывание по условию «сверхурочные», потому что сотрудник аутентифицировался вчера вечером, ведь так и должно было быть по его графику.

В настоящее время блок аналитики работает в режиме отладки и идёт «обучение» системы всем возможным ситуациям. Поиск первопричин чаще всего приводит к тому, что даже интеграторы со стороны Заказчика не обладают всей полнотой информации о том, какие на этом большом предприятии бывают смены и как это может заносится в ЗУП и в ERP. Например, тесты и разбор ситуаций выявили, что на предприятии в системе «1С: Зарплата и Управление персоналом 8» в некоторых случаях заводят так называемых «совместителей», когда есть один человек с одной карточкой для прохода на предприятие, и основную деятельность он ведёт по одному графику, а работу по совместительству – по-другому графику. В результате без «обучения» и тонкой настройки наша система сначала «думала», что это один человек, один сотрудник, работающий по одному и тому же графику, и писала в отчёт пропуски и сверхурочные. Другой пример нестандартной ситуации, которых на предприятии множество: внесение графиков т.н. «задним числом», о чём совершенно не было известно на этапе постановки задачи. Поэтому система пишет в отчёт, что, например, сотрудник 1 и 2 декабря (условно) выходил на сверхурочные работы, хотя есть график и табель, и проверка службы безопасности показывает, что эти даты – реальные рабочие дни для этого сотрудника, не сверхурочные. Оказалось, что 1 и 2 декабря графика просто не было в ЗУП, а сотрудник выходил на работу, что система рассматривает как незапланированные сверхурочные, затем, 3 декабря, график был загружен в ЗУП. Такие непредусмотренные Заказчиком ситуации вынуждают наших программистов и аналитиков закладывать в проект, в программный код и служебные отчёты много незапланированной информации, которая может пригодиться в случае разбора нестандартных и спорных ситуаций.

Примеры отчетов интеграции кадровой программы со СКУД

Рассмотрим примеры отчётов, которые формируются в программах «1С: Зарплата и Управление персоналом 8» и «1С: ERP Управление предприятием 2» для сотрудников службы безопасности предприятия:

Отчёт по выявлению несоответствий данных СКУД и табеля в "1С: Зарплата и управление персоналом"

Отчёт по выявлению несоответствий данных СКУД и табеля в 1С ЗУП

Отчёт по выявлению несоответствий данных СКУД и табеля в 1С ERP

Отчёт по выявлению несоответствий данных СКУД и табеля в 1С ERP

Например, сразу бросается в глаза, что мастер смены почему-то имеет три подозрительных сверхурочных в течение двух суток, 25 и 26 октября. Уже «обученная» система в данном случае разобрала ситуацию правильно, и в результате несложной проверки оказалось, что мастер смены действительно отработал две ночных и одну дневную смену, заменив не вышедшего по уважительной причине на работу коллегу. А вот у его коллеги в эти даты прогулов нет, так как в ЗУП на эти даты у него статус «командировка», в которой он действительно был, а выше мы писали о том, что система получает статусы типа «на работе», раз этого статуса нет, значит прогул не ставится.

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

найти прогульщика

    

Заказать интеграцию СКУД с кадровой программой предприятия. Автоматизированное сравнение данных, полученных со СКУД с графиком и табелем рабочего времени сотрудника. Анализ данных СКУД, Интеграция СКУД и 1С. Для заказа услуги свяжитесь с нашим персональным менеджером:

Наталья:  +79200-183-200, mail: 1C@agentura-soft.ru, skype: managermurom

 

Технологии
  • Интеграция с 1С: Зарплата и управление персоналом 8
  • Интеграция с 1С: ERP Управление предприятием 2
  • Интеграция с СКУД PERCO
Детали
  • Дата проекта: октябрь 2018
Заказать такую же автоматизацию
Заказать

Наши лучшие проекты