Архив метки: HR

Зачем нам HANA?

Убил полночи на поиск материалов от САП, где бы внятно было сказано зачем HCM нужна HANA. Другая архитектура — здорово, в 3600 раз ускорение правильных отчетов — офигенно. HR тут при чем? Где мы оперируем такими данными, чтобы можно было увидеть и отличить вжик от вжииик? Вендор молчит, придется самим разбираться.

Помните, раньше было модно писать хранимые процедурки на серверах баз данных? Оракл и Микрософт говорили, что для оптимизации, ускорения, инкапсуляции нужно писать логику на стороне сервера баз данных. Он же быстрый, не то что ваши приложухи на делфи и си билдере. Потом цены падали, мощности расли, и мир решил, что больше можно не мелочиться — понесли рожать горе-разработчиков, у которых «Hello world» весил десятки мегабайт. Оптимизация — не, кто здесь? Грусть и печалька. И тут САП расправляет плечи, говорит, что в SyBase в 1999 было колоночное хранилище данных, и вообще их система стала такой крутой, что надо опять бизнес-логику на базы повесить.

И теперь мы подбираемся к любопытной загадке — а какие же такие большие данные нужно обрабатывать в HCM, чтобы получить ценность от Ханы? Какая разница за 5 часов или 10 минут посчитается заработная плата, если она запускается в ночь? Отчет по ФСС считается 5 минут или 5 секунд? Лишнее время на кофе и никакой ценности.

Читать далее

Декластеризация и всем HANA

Не так давно я смотрел на красивые ролики HANA и посмеивался в кулачок. Типа решили всех обмануть красивой картинкой, в память базу затащили и поэтому все так быстро стало работать. Признаюсь — был неправ, вспылил. Почитал на днях подробнее про техническую архитектуру ханы — интересно. Я как программист старой школы жил в измерениях реляционных баз данных со строчным доступом. Потом появились в моем сознании документо-ориентированные базы. А теперь хана до меня дошла. Почитайте про column-based базы (не знаю как правильно на русский перевести).

Идея ханы очень простая — изменить способ доступа к данным и затащить все в память. В сумме это дает огромный прирост скорости, при котором работа с обычной ERP становится сопоставима с BW в части больших выборок (отчетов). Это открывает новые возможности для работы с большими данными в области ERP и HCM в частности.

Не так давно я писал про декластеризацию, еще не особо понимая, зачем она нужна. Сейчас прозрел. В HR Renewals 2 появился пульт управления расчетом заработной платы. Та самая волшебная кнопка — работать, которую любят и ждут все бухгалтера страны. Кроме того, что она красивая, зеленая, она еще умеет делать одну штуку, от которой все клиенты будут наши. Это сравнение расчета с предыдущим. Часто расчетчики спрашивают, а как можно сравнить результат расчета с предыдущим по фондам, чтобы увидеть подозрительные отклонения и найти ошибку. Получите-с. Все хана. Декластеризация позволила снять ограничения по скорости. Теперь к результатам расчета заработной платы можно обращаться быстро, мгновенно, пулей, вжик! Это означает, что мы мгновенно можем сравнить десяток тысяч табельных номеров с самими собой в прошлой жизни предыдущем периоде.

И волшебная кнопка может показать сравнение по фондам, по видам оплаты, по табельникам. Вот и быстрый способ найти ошибки в данных до того, как вся эта радость упала в контроллинг и свалилась в IDOCе из-за ограничения бюджета на СПП элементе. Кто встречал, тот молодец.

Что дальше? Декластеризация инфотипов и расчета заработной платы позволяет использовать новый механизм для аудита изменений инфотипов/данных. Появился вроде в 6 или 7 EhP. Это все теперь можно выгружать в BW и шлепать по попе пользователей за невыполнение транзакционной нормы в час. Руководители поддержки получат мгновенные KPI.

Быстрый доступ к данным открывает новые возможности для отчетности. Уже начали появляться элементы BW отчетов в ERP части. Порталы стали шуршать, а не скрипеть. Наряду с красивостями UI5 мы начали приближаться к реалтайм решениям в области управления предприятиями. Лет через цать на сотовом телефоне можно будет видеть погрузку песка в карьере в реальном времени с точностью до кубометра. В дашбордах на BOBJ Explorer 😉

Хотите еще интересностей? 😉

Зарплата в BW

Привет.

Знаете ли вы, что есть три способа получить заработную плату в BW из HR системы?

  1. Экстрактор 0HR_PY_REC_51. Самый точный и самый медленный. Экстркатор выгружает всю таблицу RT со всеми сплитами. Вообще со всеми. Соответственно, объем получается в разы больше всех остальных способов, что сказывается на производительности. Не поддерживается и не рекомендуется к использованию САПом (насколько я помню хелпы и форумы).
  2. Экстрактор 0HR_PY_PP_1. Проводки в разрезе видов оплаты. Удобно использовать для выверки с контроллингом (что уехало из HR и что приехало в FICO).
  3. Экстрактор 0HR_PY_1_CE. Выгружает заработную плату из HR в разрезе расчетного периода. Сплиты «схлопываются», поэтому нужно быть аккуратным с техническими видами оплаты, которые разбиваются по полупериодам (/001, например).

0HR_PT_2 еще граната

Так, товарищи. Печальная новость — найдена еще одна недокументированная граната экстрактора 0HR_PT_2. Точнее не так, она документирована, но специфично. В табличке V_T569R есть два модификатора (05 и 06), которые определяют временное окно, в котором BW экстрактор ищет данные для загрузки. Если вы только стартанули или нужно сделать полную загрузку данных, то нужно модификатор 05 (самая ранняя дата перерасчета) установить на дату старта (или когда у вас появились данные в системе).

Если вы уже сделали полную загрузку, отработали годик, а потом вам нужно перезагрузить весь объем данных, то увы, система выдаст данные только в указанном временном окне. Поэтому алгоритм таков:
— перед полной загрузкой (или инициализацией дельты) меняем дату на самую раннюю в табличке V_T569R.
— как закрыли год от изменений, то меняем дату на начало следующего года.
— при перезагрузке см. пункт 1.

Investigation efforts: 1 час.

Дружим HR с BW

Сегодня день цепочек — я настраивал цепочки для автоматической загрузки данных из ERP системы в BW. Цепочка, это последовательность команд, которые надо выполнить, чтобы счастье случилось. Озарившая меня идея заключается в том, что расчет заработной платы можно организовать так:

  1. Делаем модель процессов (тр. PEST) для расчета заработной платы. 
  2. В модель встраиваем шаг проводок. 
  3. После шага проводок делается минипрограмма, которая вызывает событие (EVENT) в BW системе. 
  4. Запуск цепочки в BW указываем при возникновении события (стандартная функциональность в планировщике заданий).
Таким образом сразу же после проводок у нас запустится обновление BW с уже актуальными результатами расчета. Единственное, что я сейчас пока не знаю, как научить систему автоматически передавать созданные документы проводок в целевую систему. PUST создает сами документы, но их нужно еще деблокировать и отправить. Надо поискать программку, уверен, такая есть.