Распознавание голоса в SAP HCM

Такого вы еще в HR и в SAP не видели. Прошу зафиксировать и засвидетельствовать время и дату декларации инновационного подхода к сервисам самообслуживания по теме «распознавание голоса в SAP HCM» от Поцелуева.

Многие из вас слышали про такие вещи как Apple Siri, Amazon Echo, что-то у Гугла (не знаю что). На сегодня гугл считается самым продвинутым инструментом для распознавания речи, так как обучение построено на элементах искусственного интеллекта. Нейронные сети, нечеткая логика, комбинаторика, синтез речи и прочие непонятные слова.

Так вот. В ночи игрался я с телефоном, обновляшки обновлял. И наткнулся на гугловский переводчик оффлайновый. Нашептал ему страсти в микрофон, а он мне выдал то, что на картинке выше. Сон улетел в тар-тарары. Хабрахабр сказал, что год назад яндекс и гугл выпустили свои облачные API и оффлайновые SDK для распознавания речи.

Так вот. Прислоняется к телефону человечек, томно/грозно/нудно/быстро/страстно требует 2-НДФЛ. Его волновой импульс улетает в облачный сервис гугла или яндекса, где производится трансляция в текст. А с текстом мы тоже на нашем деревенском уровне умеем. Берем регулярные выражения (regex для программеров). По ключевым словам находим объект (2-НДФЛ) и его параметры (период). Синтезируем вопрос: «Эй, ты точно хочешь 2-НДФЛ за 2016 год»? Если абонент совсем абонент, то мы отправляем заявку в бухгалтерию.

API абап умеет. Odata тоже умеет. Regex тоже умеет. Вот нам с вами и средство замещения порталов ESS/MSS. Визуализация на UI5, взаимодействие голосом. Сюда добавляем процедуру оценки персонала, утверждение/отказ заявок и … (а тут маленький секрет)…

Любопытным предлагаю погуглить или поЯндексить: https://cloud.google.com/speech/ и https://speechkit.yandex.ru/dev

Ну так, для любопытных: https://tech.yandex.ru/speechkit/cloud/doc/dg/concepts/speechkit-dg-recogn-quick-start-docpage/


Центр расчета заработной платы

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

Что нас останавливает от перехода на аутсорсинг заработной платы в SAP? Менталитет и коммерческая тайна — раз. Сложное законодательство и зона ответственности — два-с. Недостаточная информатизация — три-с. Представим, что все эти условности решены и бизнес готов перейти в облако по любым причинам. У нас появляются задачи по организации независимого доступа бизнеса к своим данным, чтобы «ну никак» не пересекаться с другими предприятиями. Последняя мода на blockchain технологию может сыграть на руку. Второй задачей является управление требованиями со стороны бизнеса, которые необходимо реализовывать для соответствия целям бизнеса. Что особенно сложно, на мой взгляд, это управление множеством требований, которые могут противоречить друг другу в рамках одной информационной системы. Реализуется ли такое в SAP? Это не корпоративный шаблон, которым можно управлять в Solution Manager. Это полноценные независимые системы в одном сервисном поле. Похоже это те задачи, которые SAP пока не может придумать как решить, чтобы можно было предложить клиентам в рамках SF.

С другой стороны, существует множество провайдеров по расчету заработной платы, налогов вне SAP. Скорее всего это те же J2EE решения с общими настройками для всех бизнесов (какие-то общие и очевидные вещи) с возможностями доработки алгоритмов на языке программирования Java под конкретного заказчика. Думаю не секрет, что доработать частный алгоритм на голом программировании существенно проще, чем настроить систему SAP под него. Разумеется, что при этом должны быть четкие политики по ведению таких разработок у самого провайдера, системы контроля версий, системы тестирования.  Где-то слышал, что сам SF написан на J2EE — на яве.

Про архитектуру высоконагруженных систем мы недавно общались. Если представить тетрадный лист в клеточку, где каждая клеточка это сервис, то получается вполне прозрачная картинка как может функционировать центр по расчету заработной платы, который будет построен на сервисной архитектуре. Например, есть какие-то специфические расчеты для конкретной отрасли, области (НПФ, налоги, льготы, социальные выплаты и пр.), и это все реализовано через сервис. Это ведет к тому, что на рынке появятся мелкие специализированные компании-сервисы, которые будут предоставлять такую услугу. На Западе это уже набирает обороты на HR рынке. Агрегаторы собирают страховые компании в пучок и предоставляют сервис по управлению страховыми планами. Сервис интегрируется в корпоративную среду и вуаля. Дальше начинает работать эффект объема и снижение цены на услугу.

Теперь представим, что такой сервис по расчету заработной платы скоро кто-нибудь реализует. Дальше вспомним последние покупки компании SAP. Не забудем, что SAP где-то в LinkedIn сказал, что развивать решение по заработной плате в Core особо не планирует. Вы поняли меня, да?


Ночные мысли 2

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

Заметьте, что и в бизнесе началось тоже самое. Компании выросли, повзрослели, все начинает падать, сложно управлять. И начинают выделяться сервисные организации, различные инфокомы, ОЦО, ЕЦО, непрофильные бизнесы и так далее. Внутри функций тоже самое. Сначала были большие отделы кадров, ОТиЗ и расчетная группа, сейчас множество сервисных функций внутри.

Что я наблюдаю в части HCM у САП. Такая же ерунда. Монстр пошел в облако, ибо своего уже не хватает (система стала слишком сложна для управления. Увеличивающееся количество ошибок только подтверждает это). Нужно масштабироваться. Облако — отлично. Следом пойдут сервисы. Сейчас SAP не умеет жить как сервис, так как ни один модуль не может существовать без OM, PA — сотрудников и организации. Технически может, разумеется, но с точки зрения бизнеса не очень.

Большинство сервисов в облаке (по крайней мере те, которыми я пользуюсь) просты — чем проще сервис, тем быстрее его примет клиент. И множество сервисов создают инфраструктуру. Мы уже привыкли к WhatsApp, Facebook, Dropbox, Office365, Evernote, что-то там еще. Они удобны потому что просты. SF тоже удобен, потому что прост. Но не сервис пока что.

Что будет дальше? Я ожидаю открытых сервисов. Каждый модуль будет равен сервису, который будет открыт как внутри системы через сервисную архитектуру (не общие таблички, а API), так и вовне. Представьте, если САП отдаст всему миру свои решения по сервисной модели? Многие игроки просто умрут. Читал, что SF обслуживал 4 млн сотрудников в своих базах. А если это будут 6 млрд? Утрирую, но намек имеет место быть. Хотите считать зарплату — берите локальный сервис и интегрируйте по открытым технологиям и протоколам. Корпоративная инфраструктура станет безумно гибкой, легкой во всех отношениях. Бизнес сможет выбирать и использовать на всю катушку то, что нужно, а не «уплочено с избытком». Интегрировать десяток стран в одно облако — проще простого и быстро, а не десятилетия. Не нравится какой-то сервис, появился лучший конкурент — заверните.

Мечты? SAP только недавно начал в Solution Manager пропагандировать релизный подход, автоматизацию тестирования, совместную работу, анализ изменений — все то, что нормальный ИТ мир использует десяток-другой лет. Жду, когда САП перейдет на Redis или memcached решения, любопытно 🙂

Кстати, сейчас неплохое время делать микросервисы. В облаке, разумеется. С открым API. И завоевывать аудиторию.


Ночные мысли про развитие в SAP

Сегодня я открыл прейскурант компании SAP и обнаружил интересную штуку. Начали исчезать лицензии на расширенную функциональность. Было и тю-тю. И вот в ночи я начал думать (отличное время для размышлений, кстати). У нас исчезают лицензии на расширенную функциональность, но появляются лицензии на секси факторс. Звучит так, что больше расширенной функциональности продаваться не будет. Звучит так, что больше мы не сможем внедрять расширенную функциональность у себя, «дома», на своих серверах. Нас принуждают идти в облака и заниматься сексом с секси ф… Звучит грубо, но увольте, под интерфейсом хочется видеть начинку. Только мы начали выстраивать красивые сервисные подходы при реализации расширенной функциональности, добавлять изящные интерфейсы через правильные технологии oData, REST, jQuery, SASS и так далее, как нам закрывают лавочку.

В Европе и США уже не нужны консультанты по классическим внедрениям. Все переходят на SF, который идеально ложится в те модели бизнеса и управления, которые работают там. Но мужику у станка на нашем заводе это … А именно этот мужик и создает прибыль компании своим трудом, его нужно искать, развивать и мотивировать.

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

Что я хотел этим сказать? Мне рынок видится в таком ключе, что вскоре будут восстребованы Web разработчики с сильными знаниями бизнес-методологии. Эти ребята смогут сделать быстро и недорого любое решение под ключ с one time fee, вместо решений SAP. Облака клиентов должны выполнять функции клиентов, а не навязывать шаблоны. Не зря нет ни одного проекта без ABAP — все компании адаптируют систему под бизнес, а не наоборот. Благо современные технологии, Open Source уже умеет то, что не умеет SAP. Это те самые мелкие кусочки конструктора, которые имеют унифицированные подходы, понятные схемы взаимодействия и открытые возможности для расширения. По аналогии с рынком фрилансеров, который постепенно опережает рынок корпораций за счет своей гибкости. Так и здесь — все новое можно сделать быстрее и качественнее вне SAP, чем внутри, и с сохранением целостности, безопасности и масштабируемости.

Заметьте, SAP за последние годы ничего не придумал нового в части отчетности. Существенный объем ABAP разработок приходится именно на формы отчетности или регламентированные документов. HANA даст возможность строить оперативную отчетности на базе BI/BOBJ, но и все. Open Source в WEB уже имеет настолько разнообразуню палитру решений для создания форм документов, отчетов, аналитики, что порой больше времени уходит на выбор инструмента, чем на реализацию.