Успешная реализация проекта по автоматизации продаж корпоративного питания в столовых предприятия горнодобывающий промышленности ТОО «Степногорский горно-химический комбинат» в городе Степногорск, Казахстан, явилась отправной точкой для развития дальнейших плодотворных отношений между нашими компаниями. Следующим (и, надеемся, не последним) стал проект по анализу данных о посещаемости сотрудников.
Как работали процессы идентификации посещаемости сотрудников до автоматизации?
Чтобы занять утром рабочее кресло в офисе, встать у станка или сесть за рычаги горнодобывающей машины, сотруднику горно-химического комбината необходимо себя успешно аутентифицировать в корпоративной системе контроля доступа (далее сокращённо СКУД). А что во всех организациях, где внедрена такая система, делает СКУД? Она просто отмечает, кто когда пришёл и кто когда ушёл. Казалось бы, данные о посещаемости работников уже есть, они хранятся в базе данных СКУД, но что с ними делать дальше? Как их анализировать? В большинстве случаев компания, в которой внедрена система контроля доступа, просто не может сопоставить эти данные с графиками, табелями рабочего времени и прочими данными из «1С: ERP Управление предприятием 2» или «1С: Зарплата и Управление персоналом 8». Отчёты, которые предоставляет любая СКУД, страдают полным отсутствием наглядности, требуют дополнительного экспорта в Excel, дальнейшей ручной обработки и анализа.
Могут возникнуть вопросы: зачем анализировать данные о посещаемости, полученные со СКУД и сопоставлять их с табелями и рабочими графиками? Как автоматически анализировать данные из СКУД ?
На таком крупном предприятии учёт посещаемости, учёт кадров, штата, плановых и реальных выходов на работу ведётся в сразу нескольких программах, никак не связанных между собой. И эта информация, как нетрудно догадаться, часто не совпадает, потому что в одном из источников она (случайно или умышленно) не соответствует действительности.
Итак, в компании существует несколько источников этой информации:
Задача стояла следующая: написать для службы безопасности предприятия систему, которая сопоставляет информацию из СКУД с табелями и графиками рабочего времени, находящихся в кадровой программе. Сформировать наглядные и понятные отчёты по отклонениям и несовпадениям между этими источниками, позволяющими выявить подозрительные ситуации.
Какие ситуации бывают на крупных предприятиях?
Эту отчётность необходимо было сделать одновременно в 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С ERP
Например, сразу бросается в глаза, что мастер смены почему-то имеет три подозрительных сверхурочных в течение двух суток, 25 и 26 октября. Уже «обученная» система в данном случае разобрала ситуацию правильно, и в результате несложной проверки оказалось, что мастер смены действительно отработал две ночных и одну дневную смену, заменив не вышедшего по уважительной причине на работу коллегу. А вот у его коллеги в эти даты прогулов нет, так как в ЗУП на эти даты у него статус «командировка», в которой он действительно был, а выше мы писали о том, что система получает статусы типа «на работе», раз этого статуса нет, значит прогул не ставится.
Несмотря на все встретившиеся технические и организационные сложности, поставленная цель была достигнута, и служба безопасности предприятия получила наглядные и понятные отчёты по отклонениям и несовпадениям между всеми источниками информации, что дало возможность быстро и оперативно реагировать на подозрительные ситуации. Количество прогулов, «прикрытых» руководством цехов и отделов, мгновенно упало до нуля (по действующему трудовому законодательству Казахстана, для начальника цеха такое деяние влечёт за собой очень серьёзные санкции вплоть до увольнения по статье), а число подозрительных ситуаций, связанных с незапланированными сверхурочными и переплатами, стремительно сокращается. Такой результат достигнут несмотря на то, что в настоящее время блок аналитики пока ещё работает в режиме отладки.
Заказать интеграцию СКУД с кадровой программой предприятия. Автоматизированное сравнение данных, полученных со СКУД с графиком и табелем рабочего времени сотрудника. Анализ данных СКУД, Интеграция СКУД и 1С. Для заказа услуги свяжитесь с нашим персональным менеджером:
Наталья: +79200-183-200, mail: sale@agentura-soft.ru, skype: managermurom
