Меню

Жесткий контроль за временем входа и выхода сотрудников

|

Началось все со случайной встречи за чашкой чая на очередном форуме SAP c Александром Дублиным. Перебросились несколькими фразами про детей и внуков, обменялись контактами, поняли, что возможно будем полезны друг другу. Польза Александра понятна – надо развивать свой информационный ресурс, а польза для меня, не совсем очевидна, но тоже объяснима. Желание не высказаться даже и быть услышанным, а желание уже передавать ОПЫТ. Потому как, со временем, все больше прихожу к мысли, что ОПЫТ – сын ошибок трудных, передается слабо. Разрывается связь поколений, от отца к сыну, к внуку, и так далее. Вместо этого у нас теперь эра ИНТЕРНЕТ – технологий, где теперь находятся и отец, и сын, и прочие родственники, друзья, знакомые, одноклассники и, конечно, Коллеги. В этой технологии, конечно, много плюсов, но есть и минусы. Отношения, позволительные в чатах, мы начинаем переносить и в жизнь, и если нас что-то не устраивает, просто исключаем из списка контактов. Ну, это меня уже понесло в философию, вернемся с ОБЛАКОВ к теме небольшой статьи, «пробе пера», так сказать. Надеюсь внесу свой вклад в «положительную» чашу весов ИНТЕРНЕТ-технологий. Возможно это выльется со временем в серию. (А возможно и нет).

Итак, пообщавшись с Александром, я понял задачу. Информационный ресурс, который он представляет, специализируется на публикации статей по конкретным проблемам внедрения ERP-проектов на базе нашего «ДОРОГОГО SAP». Статьи имеют жесткую структуру: «Проблема – Решение». Проблем, решаемых внедрением любой ERP (как и проблем внедрения), может быть много, но всегда находится Решение! Если конечно, знаешь, что внедряешь.

Кстати, возможен и другой взгляд на вещи. Решение проблемы находится в изменении бизнес-процессов Заказчика. Ведь не спроста внедряется ERP-система, значит основные БП пришли в такое состояние КАЧЕСТВА, что так дальше жить нельзя. И первое что надо попытаться сделать – это предложить Клиенту именно этот дискурс.

НО! если все-таки, Клиент настаивает, либо изменение БП – это длительный процесс (очень часто бывает, что вне рамок компетенций даже руководителя проекта), а сроки проекта «не резиновые», то есть проблему надо решать быстро и эффективно, тогда…

Итак, ПРОБЛЕМА на очередном из проектов:

Внедряется «позитивный» учет рабочего времени: интеграция SAP со СКУД (Системы контроля удаленного доступа). Одно из требований Заказчика – жесткий контроль за временем входа и выхода сотрудников в периметр «Рабочая зона». События ВХОД и ВЫХОД должны находиться в допустимых рамках ОГРВ (однодневного графика рабочего времени). ОПОЗДАНИЯ и ПРЕЖДЕВРЕМЕННЫЕ уходы ранее окончания ОГРВ – жестко фиксируются в автоматическом режиме как «ВНУТРИСМЕННЫЕ прогулы», и не оплачиваются!

Никаких ПЛАВАЮЩИХ графиков не предусмотрено. Плавающие ГРВ – когда время ВХОДА и соответственно ВЫХОДА можно задать в диапазоне от N-часов «+» «-» период времени. При этом Продуктивное рабочее время контроллируется.

Проект уже в стадии ОПЭ, выбрали 100 реальных сотрудников из различных подразделений и уже месяц, система загружает данные СКУД в SAP, модуль PT перелопачивает эту информацию в виды времени, ошибки и сообщения. Поначалу это все напоминает кашу, в которой ничего невозможно разобрать, но со временем информация структурируется и уже можно сделать массу выводов о реальной картине с трудовой дисциплиной на предприятии.

Привлек конкретный случай: сотрудник регулярно уходит с работы на 10 минут раньше окончания ОГРВ, причем каждый день. Работает в дневную 11- часовую смену, с 8-30 до 20-30, но уходит с работы в диапазоне от 20-19 до 20-21. (Рис.1)

Рис.1. Отклонения событий сотрудника от нормативного ОГРВ.

Осуществляю визит к табельщице с вопросом: «Как это можно объяснить?» и ответ: «Да, этому сотруднику позволено уходить раньше, т.к. он написал заявление, в связи с тем, что ему надо успеть на электричку. Он приходит раньше на 20 минут, и уходит раньше на 10 минут. И таких у нас с десяток.» ОПССС….. Проблема!

Изменять этот БП – не good, он сложился и c человеческой и с мотивационной точки зрения приемлем. Что можно предложить в качестве решения? Вариантов несколько:

  1. Перевести сотрудника на НЕГАТИВНЫЙ учет. На негативном учете, либо позитивном – упрощенном – по принципу «Одно касание» работают ТОП-менеджмент, и сотрудники с разъездным характером работ. Не наш случай, парень – простой рабочий.
  2. Создать графики работ-дублеры, смещенные на 10, 20, 30 минут под конкретные ситуации, и присваивать их таким сотрудникам.Это - НЕ КРАСИВО. Захламляет справочники, поддержка опять же возрастает и т.п.
  3. Поискать, а что предлагает . Вроде видел краем глаза про ОКРУГЛЕНИЕ.

Итак, идем по 3-му пути.

РЕШЕНИЕ:

После недолгих поисков в spro, находим позицию:

IMG-> Управление временными данными->  Оценка времени->  Расчет времени по точным моментам времени->  Обработка временных данных->  Округление первой и последней временной пары.

Внутри два пункта:

  • Адаптация правила расчета зарплаты - TL10
  • Адаптация схемы - функция PTIP TL10

После чтения мануала и анализа правила выясняется следующее: для определенной категории сотрудников SAP-ом разработано правило, которое позволяет округлять первую и последнюю временную пару в диапазоне 15 минут от времени начала и окончания ОГРВ. Т.е. если сотрудник зашел на работу на 15 минут раньше начала ОГРВ и вышел в течении 15 минут после окончания, то ему должен быть принят в учет просто полный ОГРВ как отработанный. Это, так называемое подготовительное время, на подготовку к рабочему процессу, оно просто обрезается. Подготовительное время: переодеться, выпить кофе, поздороваться с коллегами, включить компьютер, подготовить инструмент и т.п. Это в начале смены. И тоже самое в обратном порядке в конце смены. Таким образом в системе не появляются лишние временные пары, которые драйвер расчета все равно обрабатывает, прогоняет через всю схему, и которые в конечном итоге все равно будут удалены.

Полезный эффект: Временные пары в таком диапазоне, если их удалить заранее, не могут быть истолкованы как работа «Сверхурочная», даже если на этот период заведен «Лимит на сверхурочные-2007Ит». И в любом случае удаление этого технологического времени экономит машинное время на обработку данных, ускорит процесс расчета. В том случае конечно, если в клиентской копии схемы «ТМ00», функция «PTIP TL10» активирована. По умолчанию она «закомментарина».

Рассмотрим правило TL10 (Рис.2):

Рис.2. Правило TL10

Переведу его на русский язык. Думаю, что многие, даже консультанты HCM, не с ходу это смогут сделать.

Анализируется очередность временной пары. Надо пояснить, что в PT вся база для аналитики, это временные пары в табличке TIP (Рис.3), которые определяют: Дату\Время начала\Время окончания\Длительность\ и еще порядка 20 реквизитов-характеристик о том, откуда информация пришла, характер информации, отношение к рабочему и к сверхурочному времени, и т.д.

Рис.3. Таблица TIP

Итак, анализируется очередность временной пары. Если это ПЕРВАЯ пара, то проверяется категория сотрудников, если категория «DI» - то время начала пары, если оно не больше 15 минут от начала ОГРВ - сдвигается к началу ОГРВ. Далее проверяется, а не является ли эта пара одновременно и последней? Если Да, то проверяется время окончания. И если не больше 15 минут от окончания ОГРВ, то тоже сдвигается(изменяется) к времени окончания ОГРВ. И сохраняется. По другой ветке делается тоже самое, но только для Последней временной пары.

Во всех остальных случаях временная пара сохраняется без изменений – оператор “COLOP*”.

Возвращаемся к нашим, так сказать, проблемам.

Ясно, что правило решает другую проблему, но подход к реализации ее уже проясняется.

1. Нас интересует только последняя временная пара и только время окончания. И надо округлять ее не в сторону уменьшения, а наоборот в сторону увеличения.

2. Каким образом выделить сотрудников, для которых это правило применимо? Использовать целую категорию? После того как деление на категории сотрудников уже было не раз оговорено с заказчиком, утвердилось и используется во многих правилах и , динамических мероприятиях , и прочих местах – не КРАСИВОЕ

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев4

Комментарий от  

Вячеслав Шиболов

  |  14 декабря 2015, 09:20

Хотя я и не HCM консультант, но восхищен структурой статьи: четкость, относительная краткость и при этом полнота. Так же хочу отметить язык автора. Мой совет, не останавливайтесь, пишите еще.
 
P.S. Опыт передается плохо, поддерживаю.

Комментарий от  

Сергей Капустин

  |  15 декабря 2015, 13:53

Не согласен с тезисом "Это не красиво" в п2.
Эти сотрудники в действительности работают по индивидуальному графику. Это такой бизнес-процесс в компании. Уверен, что в Компании такой режим работы оформляется Приказом. И под него есть стандартное решение САП - график выхода. Чем проще решение, чем больше оно соответствует бизнесу, тем оно и красивее.
"Захламляет справочник"? Ну что же поделать, раз такой график есть. Нам что, гигабайты жалко?
"Усложняет поддержку"7 Вряд ли, графики все равно существуют и ведутся, а данные все равно надо менять индивидуально, но только теперь в 50ом инфотипе. Работы не меньше, а поддержка усложняется во много раз:
1) требуется специальная инструкция для обработки таких заявлений. Так как ситуация возникает не часто, то эту инструкцию никто не будет помнить на память. Лишние трудности при эксплуатации
2) Отчет - неизбежно встанет вопрос, "кто у нас работает по таким графикам? Дайте мне список" Этот отчет надо тоже написать специально, и инструкцию к нему тоже.
3) Трудность в понимании результатов работы драйвера. У руководства всегда будет вопрос, а почему у него не такое время прихода на работу? И как на него ответить, не зайдя в ему в инфотип?
И, наконец, самое главное. Плановое Нормативное задание. Не может быть такого, что бы плановое нормативное задание не соответствовало плановому времени работы. Если функционируют РР или ТОРО, то этот рабочий должен был получить сменное задание из планового расчетного времени появления его на работе. То есть, при планировании загрузки оборудования откуда-то надо знать, когда будет работать рабочий или бригада. Кроме как из графика рабочего времени это узнать, по-моему, не откуда.
Вывод - предложено очень красивое "программистское" решение, которое вынуждено компенсирует недочет, допущенный при постановке задачи - слишком поздно узнали о таких рабочих.
Однако в целом автор проделал прекрасную работу, как по сути, так и по форме изложения. И если понадобилось всего 4 часа консалтингового времени, то это несомненный успех.

Комментарий от  

Олег Книшка

  |  16 декабря 2015, 15:44

Не согласен с тезисом "Это не красиво" в п2.
Эти сотрудники в действительности работают по индивидуальному графику. Это такой бизнес-процесс в компании. Уверен, что в Компании такой режим работы оформляется Приказом. И под него есть стандартное решение САП - график выхода. Чем проще решение, чем больше оно соответствует бизнесу, тем оно и красивее.
"Захламляет справочник"? Ну что же поделать, раз такой график есть. Нам что, гигабайты жалко?
"Усложняет поддержку"7 Вряд ли, графики все равно существуют и ведутся, а данные все равно надо менять индивидуально, но только теперь в 50ом инфотипе. Работы не меньше, а поддержка усложняется во много раз:
1) требуется специальная инструкция для обработки таких заявлений. Так как ситуация возникает не часто, то эту инструкцию никто не будет помнить на память. Лишние трудности при эксплуатации
2) Отчет - неизбежно встанет вопрос, "кто у нас работает по таким графикам? Дайте мне список" Этот отчет надо тоже написать специально, и инструкцию к нему тоже.
3) Трудность в понимании результатов работы драйвера. У руководства всегда будет вопрос, а почему у него не такое время прихода на работу? И как на него ответить, не зайдя в ему в инфотип?
И, наконец, самое главное. Плановое Нормативное задание. Не может быть такого, что бы плановое нормативное задание не соответствовало плановому времени работы. Если функционируют РР или ТОРО, то этот рабочий должен был получить сменное задание из планового расчетного времени появления его на работе. То есть, при планировании загрузки оборудования откуда-то надо знать, когда будет работать рабочий или бригада. Кроме как из графика рабочего времени это узнать, по-моему, не откуда.
Вывод - предложено очень красивое "программистское" решение, которое вынуждено компенсирует недочет, допущенный при постановке задачи - слишком поздно узнали о таких рабочих.
Однако в целом автор проделал прекрасную работу, как по сути, так и по форме изложения. И если понадобилось всего 4 часа консалтингового времени, то это несомненный успех.

Спасибо, Коллеги!

Комментарий от  

Сергей Трапезников

  |  29 декабря 2015, 15:10

Системы контроля удаленного доступа -опечатка наверно, правильно системы контроля и управления доступом
 
статья нормальная.
p.s.
очень мало кадровиков, которые вообще понимают разницу между позитивным и негативным учетом рабочего времени.