Site icon SAP HR от Поцелуева

Зачем нам HANA?

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

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

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

Более того, САП начал осторожно заикаться о переносе логики на СУБД, а рендеринг интерфейсов на клиента. А мы помним, что в нормальной архитектуре должна быть реализована модель разграничения функций и полномочий, например, хотя бы MVC (Model-View-Controller). А ползет все в сторону универсальных процедурок на стороне СУБД, которые сразу будут в REST отдавать данные. А SAPUI5 их будет на клиенте отрисовывать. Вроде бы SFIN уже сделан на таких инструментах.

Представим филиальную сеть Сбербанка или Старбакса/Макдональдса. Огромная численность персонала. Огромная численность клиентов. И те, и другие представляют собой персональные данные, ходячие. Что объединяет эти персональные данные? Социальные сети и интернет. Правило семи рукопожатий и его модификации говорят о том, что твердая связь одних с другими всегда возможна. Зная об этих связях через призму их поведенческих моделей в Сети можно сделать выводы. Какие — а черт его знает, но можно. Нужно только задать правильные вопросы. Чекины людей в кафе, фитнес-клубах, различных учреждениях, географическое распределение мест работы и проживания может подсказать какие социальные пакеты компания может предложить сотрудникам. Например, фитнес-клуб в правильном месте может расположить сотрудников на его посещение, что повлияет на их здоровье (абсентеизм падает), улучшит настроение и дух (производительность вверх), сплотит коллектив (боевой дух зашкалит).

Сосредоточенное хранение информации о людях и их взаимодействии может создать ценность для федеральных служб (финансовых, социальных).

Еще мне пришла в голову ценная мысль. Я немного увлекаюсь фотографией (http://500px.com/virvit), и храню все снимки в сыром формате RAW. Эти файлы занимаюст в 5-10 раз больше места, чем обычный JPEG, но позволяют наиболее глубоко и точно отредактировать фотографию под свои требования. Десять лет назад я обрабатывал фотографии как маляр после запоя. Все было пересвечено, контраст задран и смотреть больно. А на досуге перечитал пару умных книг и заново взглянул на свои снимки. Мир стал иным 😉 При чем тут HR? Ну ребят. Надо в SAP HCM тащить вообще все что можно, что минимально связано с ФИО сотрудника или кандидата, или пьяницы, который однажды может стать генеральным директором какой-нибудь сервисной компании. Сегодня мы не умеем обрабатывать данные в разных форматах, завтра системы нас научат это делать. Не так давно сложно было распознать печатный текст с книги, только Adobe это умел. Сегодня гугл распознает образы по наброскам. Завтра SAP TREX будет всю базу шерстить и выдавать нам аналитику по человеку, включая как исправно он платит по счетам. Подумайте об этом, когда будете общаться с заказчиком. Жесткие диски стоят копейки, знания — бесценны.

На каком основание мы сейчас выставляем предложения о работе (оффер) кандидату? Как мы его собеседуем? Google Facebook, Microsoft признали пару месяцев назад, что все их изощренные тесты на нечеткую логику, нестандартные ситуации, инстинкты полная чушь. Так и мы собеседуем людей — решение принимает маленький кусочек мозга, которому человек симпатичен или нет. Остальные навыки и отношения есть результат совместного развития в замкнутой системе — работе. Кто мешает системе сформировать предложение кандидату исходя из анализа рабочего места, должностных обязанностей, результативности предыдущих попопросиживателей, социального профиля человека, и как у него дергался глаз при ответе на гадкие вопросы?

А вообще, знаете, я все больше прихожу к мысли, что консультанты скоро станут не нужны. Лучшие практики уже стали обыденностью. А количество галочек в SPRO сокращается. Все больше системы тяготеют к простейшему программированию на разных уровнях абстракции. На ассемблере мало кто пишет, а гугл и яндекс уже с голоса могут понять, что же от них хочет пользователь. Так и системы скоро будут настраиваться голосом бизнес-пользователя. Подумайте об этом. Особенно те, кто застрял в классической базе и расширке.

Exit mobile version