Куда развиваться стажеру в SAP

Вопрос:
Подходит к концу год работы в компании *** в качестве стажера, успел понастраивать систему, побывать в качестве консультанта на боевом проекте.

И вот у меня встает выбор, в каком направлении дальше развиваться: уйти в зарплату или в расширку на SF, меня больше привлекает SF, т.к HCM практически у всех стоит, проектов на рынке по базе уже практкически нет, слышал, что на западе активно внедряют SF и скоро, в теории, должно и до нас дойти + можно попробовать свои силы за границей. Или полностью сменить модуль на MM/SD, очень много вакансий и не привязан к российскому законодательству

Очень хотелось услышать твоё мнение, буду очень благодарен.

Ответ:
Скажу так. На самом деле на Западе, где я сейчас обитаю, есть спрос на SD и MM. Но он точно такой же, как и на все остальное, «популярное». Специалисты нужны везде, хотя и сложно пробиться в люди. Если ты начал работать в HCM и это не вызывает у тебя отвращения или скуку, то нет смысла менять на другой модуль. Там все тоже самое, что в HR, только в другой предметной области. Не сегодня так завтра будет свое облако, и все побегут в него под прицелом вендоров.

Насчет того, куда бежать внутри HCM я много писал здесь, в блоге, размышлял. Более того, я сам примерил на себе этот SF, стоимость его изучения, применение. Мозгами я понимаю, что в классике скоро делать будет нечего. Все уйдет в облако. Из похожего останется только зарплата, так как сап ее не меняет с переходом в облако. А душа все же лежит в классике. Ну вдохновил меня SF вообще ни разу. За эти два десятилетия развития продукта я ожидал чего-то большего как для пользователей, так и для консультантов. Банальный Learning Hub от SAP на SF и тот же Coursera, UDemy, Linda — ну две большие разницы. От LH Тошнит, а на курсере хочется учиться. В uTunes я с удовольствием проходил курсы по IOS и Swift, а к сертификации по SF готовился с напряжением.

Для тебя я, для всех, кто еще не умер в классике, только начал свой путь в сап я сегодня говорю одно — если есть возможность и реальный проект, то идите в SF. Если нет, то все равно куда, хоть на кудыкину гору, собирать одну помидору. И второе, что никто все равно не слышит и не слушает, это изучайте программирование и современные технологии на уровне Advanced User. Не будьте индусами…

Не забываем подписываться, лайкать, репостить и всячески поддерживать отечественного производителя контента!



Практические задачи на собеседовании

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

Задача 1

У человека графика 8 часов внутри них 30 минут перерыв. Оплачиваемое время 7 часов 30 минут. Но если на этот день вводится отсутствие, то оно должно считаться как 8 часов.

Задача 2

У человека график 8-8-8-8-8-В-В = 40 часов. По факту он работал 8-9-7-8-8-1-В = 41 час. 1 час сверхурочка, которую нужно оплатить. Если в пятницу человек взял отпуск, то как понять, что у него сверхурочка, и ему нужно оплатить этот 1 час?

Задача 3

У человека график 00 — 08. Если он пришел в 22 часа, перед сменой, то как ему оплатить эти 2 часа сверхурочно в сутках смены.

Задача 4

У рабочего и бригадира один график с 8 до 16. Оба пришли на 15 минут раньше. Но рабочему нужно оплатить только по графику, так как он просто раньше пришел. А бригадиру нужно оплатить доптариф, так как он составляет вахтенное задание.

Свой ответы я опубликую позже.


FAQ. Восстановление работника

Вопрос:

Как восстанавливать в системе сотрудников, которые через суд опротестовали своё увольнение. Коллега консультант говорит, что правильно — удалять все увольнения и заводить компенсацию. А заказчик хочет, чтобы увольнение в системе осталось, но чтобы восстановление не было приёмом или повторным приёмом. Например, заводить новое мероприятие.

Ответ:

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


FAQ. Тарифная сетка

Вопрос:

Необходимо реализовать тарифную сетку такого плана: все тарифы/оклады делятся на основное/вспомогательное/социальное производство. Кроме того у тарифов есть деление на «тариф при 40 час. неделе» , «тариф при 39 час. неделе», «тариф при 36 час. неделе».
Эта тарифная сетка используется на одном предприятии, не имеющим филиалов.
Пока идея такая:
TRFAR = раздел персонала, например 21,
TRFGB = раздел персонала, например 21,
TRFGR = вид производства, например основное производство,
TRFST = разряд оплаты, например 3.
А деление тарифа по длительности недели реализовать через TRFKZ:
TRFKZ=1 40-часовая рабочая неделя,
TRFKZ=2 39-часовая рабочая неделя,
TRFKZ=2 36-часовая рабочая неделя.
Беспокоит, то что группировку для ТарСогл используем не по стандарту. Чем это может для нас аукнуться при внедрении зарплаты.
Может есть другие способы для реализации такой ЕТС?

Ответ:
Для начала напомним всем, что это за поля:
TRFAR = Pay scale type (вид)
TRFGB = Pay Scale Area (область)
TRFGR = Pay Scale Group (группа)
TRFST = Pay Scale Level (уровень)
TRFKZ = ES grouping for collective agreement provision (группировка категории для тарифного соглашения)

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

В вашем случае (документы я не видел), я бы в вид тарифа положил вид деятельности (основное, вспомогательное производство), в область тарифа дополнительный признак (возможно есть какое-то разделение по графикам и схемам оплаты кроме продолжительности недели) в связке с продолжительностью (например, ABC_39, ABC_40, CDE_35), в группу вид работы/должность (слесарь), в уровень соответственно уровень оплаты/разряд/грейд.

Использовать группировку для тарифных соглашений нужно по-стандарту.


FAQ. Учебные материалы

Вопрос:

Виталий, не могли бы вы порекомендовать ресурсы ,который с вашего мнения достойны для просмотра по сап-тематике?
Интересуют относящиееся к тех . архитектуре, тестированию,  с какими-то курсами.

Ответ:

Я сам учусь на следующих ресурсах (бесплатных):

  • sdn.sap.com
  • help.sap.com
  • open.sap.com
  • SPRO
  • Support.sap.com/notes