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