HANA & декластеризация в SAP HR

Резонный вопрос, который я много раз слышал от бизнеса: «Зачем мне переходить на HANA и тратить кучу денег, если я ничего не получу взамен»? Чтобы ответить на этот вопрос, следует посмотреть на него с разных углов. Базы данных на классической архитектуре и InMemory отличаются друг от друга примерно как автомобили разного поколения. Оба автомобиля работают на двигателях внутреннего сгорания, оба могут перемещаться по твердой поверхности, но скорость передвижения, запас мощности и комфорт существенно отличаются. Не совсем корректным будет оценивать переход на новую базу данных как простую смену резины — вроде как нужно обновлять резину каждые три-четыре года, чтобы сцепление с дорогой не терять. Когда мы говорим о таком переходе, то меняется не только начинка для ИТ-специалистов, когда «что-то там» начинает быстрее работать, но и «дом, стоящий на фундаменте» становится умнее. Изменение технологий «внизу» всегда провоцирует изменение бизнес-приложений «наверху». Мало кто помнит скорость разработки приложений на языке машин ассемблере, когда многие слышали про язык программирования Swift для детей от компании Apple. В скором будущем мы сможем диктовать функции приложений и компьютеры будут самостоятельно синтезировать приложения для нас. HANA дает колоссальный прирост в скорости работы, не всегда, не во всех ситуациях, но для конечного пользователя — зачастую всегда.
Чем HANA интересная для HR бизнеса? На текущий момент я могу выделить несколько ключевых аспектов. Скорость обработки данных и формирование отчетов. В классической SAP HCM системе данных хранятся в так называемых кластерных таблицах. Это своего рода чемодан, где лежат другие чемоданчики, а внутри этих чемоданчиков лежат вещи, которые нам нужны. Если нужно что-то достать, то нужно найти большой чемодан на стеллаже, в нем найти нужный маленький чемоданчик и там найти нужный нам предмет. А таких чемоданчиков целый склад и все на стеллажах. Системе приходится очень долго бегать по складу и искать нужные чемоданы, а в них наши вещи. С переходом на HANA все маленькие чемоданчики извлекаются из больших, все вещи штрихкодируются и сразу же складываются в маркированные ячейки на стеллажах того же склада. Теперь системе не нужно открывать множество вложенных друг в друга чемоданчиков, можно по каталогу найти нужную ячейку и взять необходимый предмет. Скорость поиска данных, складирования данных возрастает в разы.
Для чего нужны такие скорости в HR? — спросите Вы. Попробуем перейти к глобальным компаниям, где в HR системе хранится и обрабатывается более ста тысяч табельных номеров. Расчет заработной платы на таком объеме может занять целый день при неплохо спроектированной системе. HANA позволит сократить это значение до нескольких часов. Это означает, что расчетный период при реализации комплекса мер может быть сокращен на целый день, а то и больше. Многие компании задумываются  о сокращении сроков закрытия финансового периода, чтобы предоставлять оперативную информацию акционерам как можно быстрее. Если HR может помочь сэкономить целый день, то это уже неплохо. С каждой бизнес-функции и неделя наберется. Уверен, что вы знаете про Payroll Control Center, в идеологию которого заложен такой механизм, как контроль качества данных. Мы можем заложить в процесс расчета заработной платы автоматизированные контрольные процедуры, которые благодаря новой архитектуре смогут очень быстро получать выборки данных в различных разрезах и указывать пользователю на ошибки или отклонения. Из того что на слуху, система может проверить наличие всех заполненных инфотипов, отсутствие значимых отклонений по каждому сотруднику в сравнении с предыдущим периодом или тем же периодом в прошлом году, проверить общие отклонения по фондам времени и заработной платы. Даже такие простейшие вещи экономят значимое количество времени.
Отчеты — то, что любит любой HR-человек от специалиста до руководителя высшего звена. Бизнес часто слышит, что нет такого отчета, другой отчет медленно работает, третий нужно подождать, пока BW «прогрузит данные ночью» и так далее. С изменением архитектуры и скорости получения данных системой из базы данных изменились и подходы к формированию отчетности.
Второй аспект, это упрощение модели доступа к данным для внешних сервисов. Мы перешли в эру микросервисов, когда человек/компания может создать сервис, который выполняет только одну задачу, но делает это чертовски хорошо. И такие сервисы собирают весь куш — клиенты к ним тянутся. Но такие сервисы не могут существовать без инфраструктуры — источников информации и потребителей информации. Сервис лишь преобразует одну информацию в другую, создавая ценность. Например, сервис страховой компании по выдаче полисов добровольного медицинского страхования получает информация от страхователя по всем сотрудникам, обрабатывает и возвращает страховые полисы. Эта простейшая задача требует доступа к данным. Если опустить технические прослойки в виде различных API сервисов, разграничения доступов, интерфейсов, то для HR функции простая модель хранения данных в системе, возможность быстро получить к ней доступ означает потенциальный выигрыш во времени. Наличие стандартизированного интерфейса открывает доступ микросервисов, предоставляющих услуги этой компании. Пенсионный фонд или налоговая инспекция самостоятельно могут получить данные для обработки. Сегодня это утопия, к вечеру уже реальность.
Переход к BigData в HR является третьим ключевым аспектом. Что такое большие данные? Это огромные массивы информации, среди которых правильно поставленные вопросы могут найти интересные ответы. Чтобы увидеть закономерности в данных необходимы простейшие модели этих самых данных (все сложное декомпозируется до простого), инструменты для анализа массивов и постановки вопросов системе и, безусловно, оперативный доступ к данным, над которыми производится анализ. Невозможно заниматься анализом, если отчеты по сотням миллионов строк формируются днями. Появление новой записи должно обогащать модель, а не заставлять систему заново формировать отчет.

Зачем нам HANA?

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

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

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

Читать далее


Будущее ABAP

Я вам еще не надоел своими умозаключениями насчет будущего?

ABAP для HANA становится другим. Скажем так, совсем другим. Большинство исходных кодов системы написано процедурным языком программирования, когда вся логика зашита в маленьких кусочках кода — процедурах и функциях. Никакого наследования, полиморфизма, инкапсуляции. Раньше так на ассемблере программировали.

С течением времени появляется объектно-ориентированное программирование (ООП). Это классы, интерфейсы, объекты. Решается много проблем процедурного программирования, но многие программисты «старой закалки» не переходят на ООП. Почему? Потому что редко нужно писать свои интерфейсы, а чаще дорабатывать и отчеты рисовать. Да и на процедурках проще, хоть и одноразово.

САП начал смотреть по сторонам, что мы наглядно видим в облачных решениях, UI. Я только что закончил читать статью про ABAP for HANA (http://scn.sap.com/community/abap/eclipse/blog/2014/02/04/new-data-modeling-features-in-abap-for-hana). Дело все в современном подходе к разработке веб-решений. Еще в 2012 году, когда я сел изучать Ruby On Rails, я столкнулся с понятием аннотации. Позже в фреймворке Symfony на PhP тоже самое для ORM моделей. Что такое аннотация? Это набор ключевых слов, параметров, которые определяют работу модели данных. Например, как модель нужно сохранить в базе данных, как модель нужно маршрутизировать (роутинг), как обеспечить целостность модели, как визуализировать модель и так далее.

Читать далее


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

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

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

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

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

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

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

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


Вопрос-ответ 10. Декластеризация таблиц

Вопрос. Декластеризация таблиц:

На проекте назрел этап формирования отчетности. Заказчик приобрел приблуду «SAP BusinessObjects Analysis» и естественно возжелал чтобы с отчетностью можно было работать в «Analysis for Microsoft Excel». И тут началось самое интересное:
1) В HANA Live как мне объяснили нету возможности работать с кластерными таблицами;
2) Ну и, как говорят наши биайщики, на экстракторы BW для HR из ERP я также могу не рассчитывать.

Сегодня нырнул в мануал и наткнулся на понятие «Декластеризация». Как результат  активировал бизнес-функция HCM_LOC_CI_50. В SPRO установил разрешение на декластеризацию для кластеров B2 и UR. А также перечислил необходимые мне таблицы (например P2RX_RT).
На этом светлая полоса закончилась и начались серые будни. При попытке выполнения транзакции «Начальная загрузка для результатов оценки времени» получил ошибку:
«№ сообщения HRDCT_MSG006

Diagnosis
The program encounter Internal error: 1

System Response
Internal error: 1

Procedure
Contact your system administrator.  After the issue solved, you can rerun the program.

Procedure for System Administration
Please check the workload of Database.
»

Читать далее