sap hcm и sap hr в чем разница
Давайте начистоту или про современный SAP HCM
Сейчас я скажу несколько грубых слов. Кто захочет, тот услышит. Дело в том, что сегодня я начал смотреть ряд курсов по последним технологиям SAP, про так называемый современный SAP HCM. Везде четко прослеживается одна единственная мысль — SAP strategy is Cloud company — САП идет в облако и на всех наплевать. Подумайте об этом. У меня есть примеры консультантов, которые считают, что их офигенные знания «базы» достаточны для хорошей пенсии. Порталы, renewals, UI, UX, Fiori и прочие модные слова им знать не к чему. Увы, мои дорогие, без этого вы никому не нужны уже сегодня. Разве что в поддержке поддержку оказывать существующим умирающим решениям. Все меньше и меньше будет внедрений с базовым функционалом, все больше решений будет на портале, так как каналы связи позволяют, техника начала позволять отрисовывать сложные экраны практически мгновенно. Терминальные доступы скоро умрут за ненадобностью, так как OData, REST и SSL покрывают все потребности в терминалах. Офисные приложения уже в облаке (MS Office 365) за адекватную цену. ОС уже интегрированы в облако. Мы по сути уже в облаке, хотя в России это пока не так явно видно.
САП тоже уже одной ногой там. Ежемесячные обновления в части Fiori, ежеквартальные аттестации в Success Factors, сворачивание продаж локальных (in-house) решений, большие скидки на облака — вы понимаете о чем речь. Надо отдать должное нашему законодательству, которое стимулирует оставаться вне облака, но и ему скоро придет конец. Рынок вынудит создать ТК РФ for Cloud. ЭЦП уже постепенно входят в нашу жизнь, бумага выходит из обихода — это первые шаги к облаку и цифровому управлению персоналом. Интернет перестал быть данью моды и перешел в разряд жизненно необходимого инструмента для эффективного ведения бизнеса. Персонал, напомню, это одна из самых емких составляющих бизнеса. Кадры все еще все.
Современный SAP HCM консультант уже должен понимать что такое UI, и чем он отличается от UX. Как правильно спроектировать приложение для решения бизнес-задачи. Вопрос переходит из области IMG в область сервисной модели, OData, OAuth, REST, API. ALE уже морально устарело. SaaS, PaaS, IaaS — те слова, которые постепенно заменяют STMS, SE09, SLD. Знание ABAP уже не так актуально, как знание Java, CSS, Mustache, Amber, HTML5, Jquery, JS. Умеем настраивать PA40 — круто, но это прошлый век. В России всего ничего внедрений простого инструмента в лице PUST (HR Process Workbench), а он уже устарел — Payroll Control Center наше все. Многочасовые отчеты заменяются BOBJ on HANA, который позволяет делать любой отчет в любом ракурсе и с плюшками. SAP Query, который мало кто умеет, тоже аттавизм. PDF и Excel формочки все больше нужны для Госкомстата и постсоветских предприятий.
Из всех этих горячих слов я лично для себя сделал один простой вывод. Через два года мои 12 лет опыта в SAP станут бесполезны, ибо мир изменится. И я сегодня это очень хорошо понимаю. Еще недавно я писал на ассемблере перехватчики 21 прерывания, подмену заголовка EXE файлы, а сегодня надо делать AJAX во фронтенд контроллере. CSS уже никто не пишет, так как есть LESS, Compass. HTML тоже мало кому нужен, так как есть DDOM. Модель OSI уже расширилась на добрые сотню процентов с былых 7 уровней. Вдумайтесь какая сегодня пропать между тапом на экране смартфона и 5 вольтами П-сигнала, который побежит к очередному контроллеру. Такая же пропасть между нашими текущими знаниями SAP и будущим через пару лет.
Похожие заметки:
4 комментария
>>Надо отдать должное нашему законодательству, которое стимулирует оставаться вне облака, но и ему скоро придет конец
Виталий, это пахнет экстримизмом 🙂 С чего это законодательству придёт конец? 🙂 🙂
Vasiliy
Как консультант SAP SuccessFactors (Employee Central), котррый уже в 2012-м понял, что SAP HR уже все, согласен с Вашими выводами.
Но по поводу бесполезности 12 лет опыта — это перегиб.
Останется:
1) Эспертиза в бизнес-анализе, навыки комуникации, связи.
2) Эспертиза в HR-процессах, законодательстве, методологии (для Core HR)
3) Интреграция с ERP и S4/HANA все равно идет через инфотипы и BAdI
4) Ну и конечно PY-шники на коне — в Employee Central Payroll схема — та же, включая локальную специфику — нужно конечно изучить и практиковаться Payroll Control Center в обязательном порядке. Хотя интерес к решениям PY, на взгляд, упал.
Ok, наброшу и от себя 🙂
Тренд сапа понятен. И достоин похвалы от любого ИТ-инженера.
Однако и на сей раз SAP по-прежнему демонстрирует полную оторванность от жизни. Во всяком случае в российских условиях.
Можно сколько угодно теоретически рассуждать про облака, про офис-365.. А на практике.. Например, в целях безопасности у сотрудников Сбербанка принципиально нет интернета. Почти ни у кого, и в этом есть логика. Какие облака?
Не знаю как устроены мозги у глав крупных клиентов вроде Роснефти, СНГ и т.п. Но лично я бы ни за что не доверил SAP AG свои базис и данные.
Это всё равно что поставить себе отличный кардиостимулятор и оставить пульт дистанционного управления у врача.
Несомненно технологии вроде UI5, FIori и т.п. будут востребованы. Но только в рамках внутрикорпоративной сети или публичных сервисов вроде оформления заявки на кредит.
Тем не менее рассчитывать на настройку PA40 до пенсии, конечно, не стоит.
>>что такое UI, и чем он отличается от UX
Сап в очередной раз открыл для себя то, чем все нормальные разработчики ПО пользуются добрые 20 лет, если не больше.
Добавить комментарий
Для отправки комментария вам необходимо авторизоваться.
Подготовка к проекту внедрения SAP HCM
Данная заметка адресуется бизнесу, заказчикам, которые начинают думать о внедрении новой системы, будь то SAP или не SAP. Мне удалось поработать со стороны заказчика, со стороны консалтинга (не только SAP), что дает чуть более широкое понимание проблем с обеих сторон. Хочу также отметить, что проблемы, или, давайте назовем это задачами, одинаковые для любой страны. Я могу судить по работе на проектах в США, Норвегии, Венгрии, России. Исключительно мой опыт.
Практически все заказчики декларируют основной задачей внедрения системы унификацию процессов, документооборота и методологии. Внедрение системы должно решить задачу унификации, так как в рамках проекта появляются внешние стимулы в виде консультантов и ограниченного бюджета проекта, когда нужно быстро поменяться и однообразиться. Заказчик по умолчанию ждет от консультанта лучших практик, которых не существует. Давайте будем честным — лучшие практики это то, как бизнес уже дорос до своего текущего состояния. Нельзя перенести практики одной компании на другую, это будут не лучшие практики, а практики той, другой компании. Но это удобно, так как позволяет посмотреть, точнее подсмотреть, а как же сделано у других. Человеческое любопытство, когда сам придумать не можешь, поэтому идешь за идеями к соседу и их улучшаешь под себя.
В рамках проекта консультанты опираются на задачи проекта и требуют бизнес унифицироваться. Получается такая ситуация, когда бизнес самого себя просят самостоятельно устаканиться и отдать за это деньги чужим людям. Я также в свое время мотивировал себя ходить в спортзал — раз заплатил, то «нуна ходить». Сама по себе унификация тоже не очень понятный процесс. Представьте большой бизнес, где множество компаний, разные функции, разная иерархия управления. Простой пример: крупный завод на десятки тысяч персонала и малюсенькая компания с продавцами продукции на экспорт. И это все в рамках одного объема проекта, где должны быть унифицированные процессы, документы и методики. Для одних мельчайшее изменение аукнется численностью, фондами, эффективностью закрытия периода, другие вовсе не заметят. А упразднение одной из премий для первых пройдет просто другим видом начисления, а вторым может похоронить мотивацию продавцов. Потому что унификация.
Отчетность, особенно внутренняя, является еще одним камнем в огород обеих сторон. Бизнес говорит, что нужны отчеты, обычно в установленных формах, а консультанты предлагают «какие-то странные выгрузки из системы в кривом формате». Возникает конфликт устоев и прогресса, в котором обычно побеждает сложившаяся практика на предприятии по документообороту. Если справка по физобъемам должна лежать каждое утро у начальника цеха на столе, то никакая система не поможет пока начальник не начнет открывать систему по утрам. На западе такая практика встречается реже, когда заказчик требует формирование бумажных отчетов. Люди работают с современными технологиями дольше и больше, поэтому безбумажный документооборот развит и проекты запускаются проще. Разумеется, что это не касается законодательной отчетности.
Методология это самый большой объем работы на проекте. Скажу по секрету, что часто говорят о необходимости унифицировать процессы, а на практике процессы занимают процентов 10 от реальной работы по унификации. Основное это бумажки и расчеты, и зачастую это связано с требованиями законодательства, в то время как процессы практически не регламентируются законами. Под методологией я понимаю алгоритмы расчета тех или иных величин, правила заполнения отчетов и выходных форм. На входе в проект заказчик любит оперировать цифрами 80/20, 70/30 или иными конкретными величинами измеряющими результат унификации. С одной стороны какая разница сколько будет видов оплаты, ведь это всего лишь справочник? А с другой стороны необходимо на всех уровнях понимать что такое фонд оплаты труда, что такое затраты на персонал (это понятие обычно шире, чем фонд оплаты труда). В моем понимании идеальная унификация стремится к нулю, к упрощению до максимального уровня, не противоречащего закону и целям бизнеса.
В рамках проекта, когда дело доходит до унификации методологии, возникает множество сопряженных с HR вопросов из области налогового учета, экономики предприятия, бухгалтерского учета, юридической. Часто у этих областей нет единого держателя, который может со своей высоты принять решение о единообразии. Каждое подразделение варится в своем соку, что вскрывается на обсуждениях того же каталога видов оплаты (прошу прощения за банальный пример, но это самое больное место во всех проектах по SAP HCM).
В западной практике я встречал такой подход. Есть основная часть заработной платы — оклад или тариф. Его формирование устанавливается по единому алгоритму для всех категорий сотрудников независимо от способа учета и характера работы. Эту базовую часть все подразделения понимают одинаково. Мотивационная часть (премии, надбавки, доплаты) формируется из нескольких основных видов начислений, которые называются общими словами (например, «Премия за результат», «Премия за качество», «Надбавка за условия труда» и пр.), а что внутри этих начислений отдается на откуп каждому подразделению. Так «Премия за результат» у продавцов содержит один смысл, у рабочих другой, у ТОПов третий. И неважно как считается эта величина. С точки зрения управления персоналом это одна сумма, которая должна быть рассчитана и предоставлена ответственным подразделением. Как это подразделение рассчитает и управляет этим начислением никого не волнует, так как это прямая ответственность руководителя этого же подразделения. Такое решение идеально вписывается в концепцию унификации: количество алгоритмов в зоне внимания HR минимально, мотивация каждой группы персонала определена в зоне соответствующего предприятия или подразделения, понимание фонда единое у всех, головная боль HR стремится к нулю, так как функция децентрализована. Отсутствие автоматизации? Отнюдь. Так как каждое подразделение или предприятие живет в своем темпе (своя система мотивации, свои показатели, свои скорости работы и оценки результатов), то каждое подразделение самостоятельно озабочено инструментарием для эффективного выполнения этой функции. Кому-то достаточно Excel раз в год, а другим нужна онлайн интеграция с производственными системами. Но эти задачи переходят в зону ответственности этого подразделения, и оно лучше HR знает как выполнить эту задачу эффективно.
План мероприятий по подготовке к проекту внедрения SAP HCM
Сломайте, чтобы построить. Этот подход часто используется в задачах по построению интеграции между системами. Отключите одну систему и посмотрите, что произойдет. Если ничего не произойдет, то эта система или связь не нужны. На практике это означает планомерное отключение (избавление) шагов по передаче отчетов из одного подразделения в другое, сокращение использования тех или иных справочников (виды оплаты, графики, временные данные, НСИ). Очень часто при новом внедрении системы бизнес хочет перенести все что есть. Но никто не может сказать для чего. Множество аналитик были реализованы по тем или иным причинам годы назад для конкретного случая, который уже неактуален, но эту аналитику все еще продолжают заполнять по инерции. Какие управленческие решения принимаются сегодня на основании этой аналитики?
Формирование отчетов и документов зачастую связано с тем, что люди, которые получают эти документы, не оснащены автоматизированными рабочими местами. Наиболее типичный примером может служить бюро пропусков и служба безопасности. Вечные заявки на бумаге за подписью ответственного должностного лица. Может стоит дать им возможность иногда играть в пасьянс на ПК? Стоимость автоматизированного рабочего места может оказаться дешевле бумажного документооборота.
Процессы. Пожалуй это самое популярное слово при внедрении. Все хотят упростить, унифицировать процессы. Если посмотреть на процессы после внедрения SAP и до, то отличий будет не так много, сколько было шума вокруг этого. Унифицировать процессы без привязки к системе очень просто. Берем самый простой вариант процесса и самый сложный (как выше в примере с заводом и продавцами). Смотрим чем они отличаются (с большой степенью вероятности отличия будут в количестве коммуникаций и выходных формах), приводим процессы к наисложнейшему по всем предприятиям. А потом откусываем шаги согласно первому принципу «сломайте, чтобы построить». Не нужно строить красивых диаграмм и поэм — в реальной повседневной жизни никто не заглядывает в эти многотомники. Простая табличка в Excel поможет.
Бумажки. Вторая после методологии больная тема. Бумажки это все то, что не нужно закону. В одной компании был проведен эксперимент с изъятием принтеров. Люди физически не могли напечатать документы. Через полгода количество документов по электронной почте сократилось в разы. Вместо «где отчет?» стал возникать вопрос «где посмотреть?». Я верю, что есть документы, которые нельзя унифицировать. Например, дополнительные соглашения к трудовым договорам. Достаточно переработать документы по наиболее массовым случаям и их унифицировать и автоматизировать. Все остальное вынести за рамки проекта и унификации как в ситуации с премией за результат. При массовом подборе и найме в розничном бизнесе документы легко унифицируются и автоматизируются, но зачем это делать для промышленных гигантов?
Люди и проект. Это самая щепетильная тема. Любой управленец знает, что люди болезненно воспринимают изменения. Даже перестановку стола в кабинете можно считать за объявление войны, неуважение к отданным предприятию лучшим годам жизни. Начиная проект по внедрению такой системы, а это большой проект, каждый его участник со стороны бизнеса морально чувствует, что это временно и против него. Даже руководитель проекта имеет опасения, что после проекта его роль завершится, и он станет не нужным предприятию. Перед стартом проекта у людей должно быть четкое понимание, что с ними случится после завершения проекта. Любой проект это стресс, это дополнительная работа, которая отличается от привычной. Многие участники проекта рассматривают это как допнагрузку, которая никак не компенсируется. Стоит заранее подумать о мотивации людей работать в проекте эффективно, а не из под палки «иначе уволим».
Коммуникации или «а поговорить». Многие руководители стали руководителями потому, что они начали или умели разговаривать. Правильно формулировать и доносить свои мысли до собеседника. Когда начинается проект, то об этом забывают. Проект подразумевает вовлечение большего количества людей, чем мы привыкли видеть ежедневно. Появляется новый барьер, который нужно преодолеть, чтобы достичь результата. Но вот незадача — нет мотивации. Зачем идти и разговаривать с кем-то, если лично мне это ничего не даст. Со своим руководителем или подчиненными — всегда пожалуйста, так как стимулы понятны. А тут совершенно другие люди (как в бизнесе, так и внешние консультанты), результаты общения с которыми не предвидят никакой мотивации. В итоге мы видим постоянный недостаток информации у всех участников проекта на всех уровнях. Чтобы снизить потенциальные риски из-за коммуникаций еще до проекта нужно выстраивать правила общения. Не формальные регламенты кто, куда, зачем и когда, а нечто иное. На практике это может быть организация проектных инициатив, которые в стратегическом плане приведут самих участников к пониманию необходимости внедрения новой системы. Раньше на предприятиях были такие штуки как «рацухи» — рационализаторские предложения, реализация которых сделает предприятие или процесс в чем-то лучше. Это и есть проектная инициатива, которая может вовлечь большое количество людей без объявления проекта, подготовив тем самым и команду, и бизнес к изменениям.
Самое главное, с моей точки зрения, как и многократно ранее было замечено в других статьях, это максимально точно донести цель внедрения до наибольшего количества людей в компании.
11 ЭТАПОВ ЭВОЛЮЦИЯ SAP ERP
11 этапов эволюции архитектуры SAP ERP
Понять архитектуру SAP ERP новичку может быть довольно сложно. Самый простой способ это сделать — проследить за ее развитием с самой первой версии системы SAP.
Автоматизация бизнес-процессов
С развитием компьютерных технологий в компаниях возрастал интерес к автоматизации различных бизнес-процессов, поскольку это позволило бы заменить непроизводительный и подверженный ошибкам ручной труд. Чтобы создать приложения, которые помогли бы им это сделать, компании нанимали разработчиков в штат или привлекали для этого другие компании.
Такие приложения создавались для конкретных бизнес-потребностей, но обслуживать их было довольно тяжело: документация была написано плохо; не все умели пользоваться этими приложениями, а те, кто умели, со временем уходили из компании; из страха «сломать» приложение за его модификацию никто не брался. В результате люди годами использовали устаревшие разработки и у каждого отдела было собственное программное обеспечение, которое никто не пытался интегрировать в единую систему.
Самое мощное в мире ERP-решение было создано в IBM
Пятеро (уже бывших) сотрудников IBM — Дитмар Хопп, Ганс-Вернер Гектор, Хассо Платтнер, Клаус Чира и Клаус Велленройтер — заметили, что бизнес-приложения, которые они создают для разных компаний, похожи.
Тогда они предложили руководству создать одно стандартное программное обеспечение, которое исключило бы разработку одинаковых приложений в будущем, а также позволило бы решить проблемы с недостаточно хорошо разработанными в самих компаниях программами. Такое решение можно было бы использовать на многих предприятиях, что, соответственно, позволило бы сократить затраты на разработку и техническую поддержку.
Однако IBM эта идея не понравилась. Поэтому в 1972 году они создали собственную компанию под названием Systemanalyse und Programmentwicklung (Системный анализ и разработка программного обеспечения), которую затем переименовали в Systeme, Anwendungen und Produkte in der Datenverarbeitung (Системы, приложения и продукты для обработки данных).
Системы, работающие в режиме реального времени: начало
Свое первое программное обеспечение для бухгалтерского учета на базе DOS — систему R/1 — специалисты SAP разработали в 1972 году. Затем, в 1979 году, на базе мейнфрейма была создана система SAP R/2. Система SAP R/2 включала практически все необходимые предприятиям функции: логистику, производство, бухгалтерский учет и кадровые ресурсы. R/2 также поддерживала несколько языков и валют, что сделало ее популярной в международных компаниях.
Трехуровневая клиент-серверная архитектура
В 1992 году разработчики SAP изменили существующую систему, создав SAP R/3 — решение на основе клиент-серверной архитектуры. В этой системе доступ к приложениям можно было получить с нескольких компьютеров, а данные этих приложений обрабатывались с помощью одной или нескольких баз данных.
Разделение решения на три уровня (презентационный, уровень приложений и уровень баз данных) и клиент-серверная архитектура позволяли организациям запускать каждый из уровней на отдельных машинах.
Презентационный уровень здесь выполнял роль клиента, а уровень приложений — сервера, схожим образом уровень приложений выполнял роль клиента, а уровень баз данных выполнял роль сервера. Как оказалось, подобная архитектура имела большой успех.
Функциональные модули SAP, отраслевые решения и технологический уровень
Уровень приложений состоял из нескольких базовых модулей: управление материальными потоками, сбыт, управление персоналом, планирование производства, финансы и учет затрат и т. д.
Решения для отдельных отраслей производства поставлялись в качестве надстроек. Чтобы компании могли использовать необходимые для их сферы деятельности бизнес-процессы, необходимо было установить соответствующую надстройку отраслевого решения (Industry Solution Add-on). Эти производственные надстройки позволяли немного изменить стандартный набор базовых модулей, чтобы решение SAP можно было применять в различных отраслях.
Такие приложения создавались на технологической платформе под названием SAP Basis (которая в будущем также будет называться Web Application Server или NetWeaver Application Server). Платформа SAP Basis позволяла запускать систему SAP на различных операционных системах и с различными базами данных.
Решение SAP R/3 до версии 4.6c, EnjoySAP, и что произошло с SAP R/3 4.6D
Теперь, взяв в качестве точки отсчета SAP R/3, давайте посмотрим, как развивалась архитектура SAP ERP.
Итак, вплоть до версии 4.6c SAP R/3 имеет следующую архитектуру:
До выпуска версии 4.6D платформа Basis была обязательным компонентом только SAP R/3. Поэтому у Basis и у R/3 одинаковый номер версии, а также один пакет поддержки.
После создания в 1999 году интернет-среды mySAP.com специалисты SAP начали поставку некоторых прикладных компонентов, например, SAP R/3 или SAP New Dimension Products (Продукты нового измерения SAP), разработанных на базе SAP Basis. Затем, поскольку платформа Basis была отделена от SAP R/3, дальнейшее ее развитие зависело от прикладных компонентов среды mySAP.com и их технических требований.
Версия SAP Basis 4.6D, которая используется с такими компонентами mySAP.com, как рабочее место (Workplace), хранилище бизнес-информации (Business Warehouse, BW), хранилище информации (Knowledge Warehouse, KW), система управления отношений с клиентами (Client Relationship Management, CRM) и др., не использовалась ни в одной из версий R/3. Следовательно, хотя решение Basis 4.6D и существовало. Решение SAP R/3 4.6D так и не вышло в серию, ни одна из версий R/3 не была сделана на базе Basis 4.6D.
Расширения для предприятий и система SAP R/3 Enterprise
В конце 90-х годов, благодаря распространению языка разработки Java, получили широкое распространение две главные технологические разработки: стандарт Юникод и появление всемирной паутины (см. пузырь доткомов).
Следуя последним технологическим трендам, разработчики SAP решили изменить базовый уровень системы. Платформа Basis была переименована в Web Application Server (Сервер веб-приложений) или Web AS, что подчеркивало использование новых технологий. Однако имя Basis не было забыто, и все эти термины на сегодняшний момент взаимозаменяемы.
Особенно важным изменением в архитектуре стало создание расширений.
Расширения — это небольшие программы, устанавливаемые поверх базовых приложений, которые содержат новые дополнительные функции, благодаря которым изменять базовые приложения нет необходимости. Если улучшение появляется в нескольких расширениях для предприятий, то, скорее всего, вскоре оно станет частью базового приложения: все изменения и улучшения сначала предлагаются в качестве расширений.
Интеграционные компоненты, MySAP ERP 2003 и SAP NetWeaver
Пока мы еще не перешел к приемнику SAP R/3 Enterprise, давайте посмотрим, как под одним названием SAP NetWeaver специалисты SAP объединили несколько значительных новых компонентов и платформ, и как решение SAP R/3 Enterprise было расширено за счет дополнений.
До Web AS 6.10 (ранее Basis) возможности HTTP использовались благодаря серверу транзакций Интернета ( Internet Transaction Server, SAP ITS), а XML-данные обрабатывались с помощью бизнес-коннектора ( SAP Business Connector, SAP BC). И сервер, и бизнес-коннектор поддерживали данные в формате HTTP/XML и конвертировали их в формат прокола DIAG (DIAG используется графическим интерфейсом SAP GUI для взаимодействия с уровнем приложений).
Веб-приложения (которые называются Internet Application Components — прикладные Интернет-компоненты или IAC), например, приложение для системы самообслуживание сотрудников, были созданы специально для SAP ITS. Сервер транзакций Интернета существует до сих пор, он интегрирован в ядро SAP, однако теперь это не единственный инструмент, который облегчает работу HTTP-протокола сегодня.
Благодаря Web AS версии 6.10 система SAP также поддерживает HTTP и XML, используя для этого менеджер связи через Интернет ( Internet Communication Manager, ICM). Страницы бизнес-сервера (Business Server Pages, BSP) были разработаны для выполнения бизнес-задач в браузере, подобно тому, как выполняются транзакции с помощью SAP GUI.
Как и с Basis 4.6D, системы SAP R/3 на базе Web AS 6.10 не существует.
А теперь перейдем к Web AS 6.20. После приобретения компании In-Q-My и принадлежащего ей сервера приложений Java, разработчики SAP добавили к линейке продуктов платформу SAP J2EE.
Доступность языка программирования Java в Web AS сделала возможным использование таких программных компонентов, как система управления взаимоотношений с клиентами (SAP Client Relationship Management или CRM), портал предприятия (SAP Enterprise Portal, EP) и инфраструктура обмена данными (SAP Exchange Infrastructure, XI). Компания SAP сгруппировала интеграционные компоненты — инфраструктуру обмена данными, портал предприятий, управление информацией (Knowledge Management, KM) и хранилище бизнес-информации (Business Warehouse, BW) — и назвала их SAP NetWeaver. Функцией этой группы компонентов была помощь в интеграции различных приложений в системы предприятии с помощью открытых стандартов.
Несмотря на неоднородную ИТ-среду компонент интеграции пользователей ( People Integration) позволяет оперативно предоставлять сотрудникам доступ к различным системам и функциям. Данные на предприятии находятся везде: как структурировано, так и не структурировано. Интеграция данных ( Information Integration) позволяет упорядочивать эту информацию и анализировать ее. Бизнес-процессы происходят в различных системах как внутри, так и вне организации. Компонент интеграции процессов ( Process Integration) создает инфраструктуру для интеграции всех этих процессов. Платформа приложений ( Application Platform) состоит из Web AS JAVA, Web AS ABAP и поддерживает сторонние и/или принадлежащие SAP операционные системы и базы данных.
Компоненты NetWeaver расположены таким образом, что вместе они напоминают отсеки холодильника, поэтому архитектуру NetWeaver часто так и называют — холодильник.
Основа SAP NetWeaver — платформа приложений (Web AS ABAP и Web AS JAVA), в то время, как само решение SAP NetWeaver — основа для других решений SAP, например MySAP ERP. Функционал, обслуживание которого было невозможным на уроне Basis, теперь стал возможны благодаря NetWeaver.
Архитектура MySAP ERP выглядит следующим образом:
Неизменяемые плагины стали частью системы NetWeaver (их так и называют NetWeaver Plug-Ins ).
Архитектура для корпоративных служб, MySAP ERP 2004 и NetWeaver 2004
Если вы откроете HTML-страницу в браузере, чтобы, скажем, посмотреть контактную информацию какого-нибудь человека, все данные отображаются на странице и вы можете найти все, что нужно. И если из всей информации, которая будет там, вам нужен только номер факса, отделить эту информацию от всей остальной будет нетрудно.
Однако если вам необходимо создать программу, которая выполняла бы такую же задачу, вам нужно написать определенный порядок действий, с помощью которого программа сможет отфильтровать всю ненужную информацию, чтобы найти номер факса. Благодаря веб-сервисам ( Web Services) все стало проще. Следуя тщательно проработанному порядку действий, веб-сервисы получают необходимый результат (в этом случае это номер факса).
А поскольку веб-сервисы работают на базе открытых стандартов, не имеет значения, на каком языке программирования или с какого аппаратного обеспечения был отправлен этот запрос и на каком языке и на какое оборудование веб-сервисы было дано задание отправить полученный результат.
Каждая веб-сервис выполняет определенные действия. Зачем служебной программе нужен номер факса, если она ничего не будет с ним делать? Вероятным продолжением последовательности этих действий будет отправить счет-фактуру посреднику и записать, что факс был отправлен (успешно или нет).
Представьте набор из нескольких веб-сервисов, объединенных в одну: одна бы брала номер счета-фактуры в качестве входных данных и находила с помощью него идентификационный номер посредника, вторая определяла бы номер его факса, третья бы отправляла этот счет-фактуру по факсу с помощью еще одного веб-сервиса, а четвертая обновляла данные об этой счете-фактуре, указывая результат отправки. Такой веб-сервис называется веб-службой для предприятий ( Enterprise Web Service ).
Веб-службы для предприятий являются своеобразными кирпичиками бизнес-процессов. Основное приложение SAP (SAP R/3 Enterprise) переняло основанную на веб-службах для предприятий архитектуру (Enterprise Services Architecture). Из-за этого изменения ядро SAP R/3 Enterprise получило новое имя — SAP ERP Central Component, ECC (Центральный компонент SAP ERP). А архитектура Enterprise Services Architecture была позднее переименована в Enterprise Service-oriented Architecture, ESoA (Сервисно-ориентированная архитектура предприятия).
Вроде бы понятно, но что в этом особенного?
Представьте, что у вас есть CD-плеер: он состоит из устройства считывания CD-дисков, блока питания, усилителя и динамиков. Если это можно приравнять к стандартному бизнес-процессу, то ничего больше не нужно. Но если другой бизнес-процесс — это DVD-плеер, то вам нужен проигрыватель для DVD-дисков, который также будет состоять из устройства считывания DVD-дисков, усилителя и динамиков, т. е. отчасти из тех же самых деталей. Если каждую из деталей считать отделяемой веб-службой, то вы вполне сможете использовать блок питания, усилитель или динамики СD-плеера, чтобы подключить их к устройству считывания DVD-дисков и получить из этого готовый DVD-плеер. И все это благодаря так называемым «веб-стандартам». Повторное использование было возможно и раньше (например, с помощью функции RFC), но в основе не лежали открытые стандарты и поэтому интеграция была довольно трудной.
Хранилище бизнес-информации (BW) и сервер транзакций Интернета (ITS) теперь были включены в NetWeaver по умолчанию. Службы стратегического управления предприятием(SEM), которые зависели от хранилища бизнес-информации, и сервисы самообслуживания, работавшие на базе сервера транзакций (помните веб-приложения?), больше не были дополнительными компонентами системы, а стали частью ядра ECC.
Изменения в NetWeaver и в архитектуре ECC.
После выхода решения MySAP ERP 2005 (позднее переименованного в SAP ERP 6.0) меняется взгляд на NetWeaver, подходам к его установке и использованию.
Сотрудники SAP выяснили, что отдельные компоненты NetWeaver используются ИТ-отделами не для того, чего они предназначались. Например, сервис бизнес-отчетности и запросов (Business Reporting and Querying) состоит из хранилища бизнес-информации, портала предприятия и хранилища информации (исходные компоненты NetWeaver).
Вместо того чтобы разделить NetWeaver на отдельные компоненты, специалисты SAP начали группировать их в отдельные блоки, которые можно устанавливать отдельно, и назвали их Usage Types (Типы использования), которые позволили бы реализовать ИТ-сценарии и процессы.
Источник: документация SAP — What’s New with SAP NetWeaver 2004s_0_
Раньше, если вам нужно было использовать инфраструктуру обмена данными XI, сначала необходимо было установить Web AS ABAP, затем Web AS JAVA и только затем компоненты приложения XI. Теперь же достаточно установить SAP NetWeaver Process Integration Usage Type (Тип использования — интеграция процессов SAP NetWeaver), и он автоматически выберет необходимые компоненты для установки.
Отдельные компоненты (здесь приводятся для справки) имеют такие же номера версии, кроме MDM-решений. Это SAP NetWeaver версии 2004s; где «s» обозначает комплект (от англ. suite — комплект). Позднее это название было изменено на SAP NetWeaver 7.0.
Мы продолжим использовать схему «холодильника», поскольку типы использования до сих пор состоят из этих же компонентов.
Ядро ECC теперь включает отраслевые решения (Industry Solutions) в качестве расширений. Предприятиям не нужны все расширения, некоторые расширения не нужны даже полностью.
Расширения для интеграции состоят из набора отраслевых бизнес-функций ( Industry Business Function Sets ) и отдельных отраслевых бизнес-функций (Industry Business Functions), которые могут быть активированы на основе потребностей каждой отдельной компании. Активировать бизнес-функции / наборы бизнес-функций различных отраслевых решений одновременно невозможно. Если функции активированы, то, как правило, отключить их тоже невозможно.
Активация бизнес-функций / наборов функций возможна при использовании архитектуры переключения ( Switch Framework ). Объекты репозитория (приложения, модули функций, таблицы, службы предприятий и т. д.) предоставляются компаниям неактивными и при необходимости могут быть активированы с помощью этого внешнего средства управления.
Расширения для предприятий, которые были представлены еще в версии R/3 Enterprise, состоят из основных бизнес-функций / наборов функций (General Business Functions/Sets). Можно активировать одно или более из этих расширений, поскольку они по своему характеру подходят различным сферам деятельности.
Пакеты улучшений включают упрощенный пользовательский интерфейс (позволяет проще запускать транзакции), функциональные и отраслевые улучшения и службы для предприятий.
Следующий большой шаг в эволюции системы
Мобильные устройства стали для нас продолжением компьютеров. Все больше и больше бизнес-транзакций запускается с помощью сенсорного пользовательского интерфейса. Затраты на интернет-услуги падают, компании создают бизнес-среды в облачных сервисах или полностью переносят все бизнес-процессы в облако. Объем данных компаний огромен, и для управления им необходимы мощные аналитические алгоритмы.
Поэтому специалисты SAP создали базу данных и производительную прикладную аналитическую программу под названием HANA. База данных SAP HANA может быть запущена в ОЗУ и функционировать в построчных, колоночных и объектных таблицах.
SAP работает над модификацией ядра ECC: оно должно поддерживать только SAP HANA, оттуда убираются все ненужные таблицы и индексы, добавляется супертехнология по сжатию данных, которая позволит сократить объем хранящихся данных.
Источник: материал курса openSAP SAP S/4HANA in a Nutshell
SAP ERP переименовали в SAP S/4 HANA. Буква «S» означает, что модель данных была упрощена (от англ. simplify — упрощать). Цифра «4» означает, что это четвертое поколение решения, после SAP R/2, SAP R/3 и SAP ERP. Как и предшественник этой версии решения, система S/4 HANA базируется на базе SAP NetWeaver и доступна для локального, облачного или гибридного развертывания.
Отдельные модули упрощаются постепенно. Модуль упрощенного финансирования SAP Simple Finance доступен уже сейчас, а модуль логистики SAP Simple Logistics будет доступен к концу 2015 года.