Подключение новых типов объектов, доступных для транзакции MASS – массового изменения данных в SAP ERP

Аннотация к комментарию

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

Довольно часто возникает необходимость массового изменения данных в SAP ERP. Например, это данные технических мест или данные карточек ОС. Делать обновление данных в таблицах системы «вручную» категорически запрещено, допустимо только изменение данных с использованием стандартных транзакций системы так, чтобы информация об изменениях осталась в журналах обработки и т.д.

Компания SAP предоставляет программные интерфейсы в виде функций BAPI, которые позволяют выполнять изменения объектов путём написания собственной Z-программы массовой обработки данных. Разработка Z-программы такого рода обычно состоит из следующих шагов:

1. Запрос параметров выбора объектов для обработки, т.е. получение у пользователя информации о том, какие данные требуется массового обработать/изменить.
2. Выбрать требуемые данные, показать списком текущие значения полей объектов, которые будем изменять.
3. Запросить у пользователя, какие значения полей и по каким условиям требуется изменить и на какие значения выполнить изменения.
4. Выполнить изменения согласно заданным пользователем параметрам.
5. Показать журнал обработки объектов.

Если теперь перевести эти соображения на язык программы, то скорее всего самой сложной частью работ будет обработка диалога с пользователем, так как шаг 4, при наличии соответствующих BAPI-функций (в крайнем случае, можно использовать пакетный ввод) занимает в среднем около 20% от всей разработки. Используя предложенные ниже инструкции, вы сможете сэкономить порядка 80% времени при решении задач массового изменения данных, также получите унифицированный интерфейс для работы с изменениями любых объектов системы конечным пользователем.

В системе SAP ERP есть хорошая транзакция для выполнения массового изменения данных – MASS, которая позволяет это выполнять такие операции. Описание работы с транзакцией MASS приведено в комментируемой статье.

Когда у меня появилась задача массового изменения карточек ОС (Основных средств), я попытался использовать транзакцию MASS, но обнаружил, что она не работает с типом объекта «Техническое место». В стандартной системе перечень типов объектов, с которыми работает данная транзакция невелик. Стандартный список объектов транзакции MASS, приведен на рисунке MASS-01.png.

Я задался целью расширить список типов объектов, данных которых можно массово изменять с помощью данной транзакции, объектом «Техническое место». В данной статье описывается методика (пошаговое руководство) такого расширения.

Рис 1. MASS-01.png: Стандартный список объектов транзакции MASS

1. Добавление нового объекта

Нужно задать имя бизнес-объекта для объекта «Техническое место». Имя можно добавить любое. Существующие в системе имена типов объектов, используемых в транзакции MASS, можно увидеть через код поиска в таблицах:

• MASSFUNC (Массовое изменение: функции для обновления базы данных, сюда следует свой тип объекта и его параметры).
• MASSNAME (Тексты к объектам массовых изменений, сюда следует добавить текст, описывающий добавляемый объект).

После добавления в эти таблицы «вашего типа объекта» он будет отображаться для выбора в транзакции MASS. Для ввода требуемых данных можно воспользоваться ракурсом ведения, транзакция SM30: MASSFUNC, в которой добавим наш новый тип объекта – «Техническое место».

Примечание

Так как для объектов «Техническое место» в системе есть код бизнес-объекта, то воспользуемся существующим именем. Определить имя бизнес объекта, можно используя таблицу TOJTB – Основные данные репозитария бизнес-объектов. Для этого нужно зайти в просмотр данных таблицы и через код поиска значений к полю NAME можно определить, какие есть бизнес-объекты для технических мест. Как видим, в системе существует 4 типа объекта (см. Рис. 2: MASS-02.png), мы возьмём BUS0010, чтобы было похоже на то, что есть в таблицах транзакции MASS. Еще раз напоминаю, что на самом деле никакой связи транзакции MASS с данными бизнес-объектов нет, поэтому будет ли это имя из таблицы TOJTB или же это будет ваше собственное имя, в принципе все равно, но в целом для поддержания общих принципов наименования объектов, правильно будет использовать имена стандартных бизнес-объектов из таблицы TOJTB.

Рис 2. MASS-02.png: Выбор типа объекта

Добавим в ракурсе ведения MASSFUNC, следующие данные, Рис. 3: MASS-03.png.

Рис 3. MASS-03.png: Добавление данных в в ракурсе ведения MASSFUNC

Имя объекта берем из таблицы TOJTB, указав в комментарии, что это объект массового изменения для технических мест, далее имя функции: Y_TSH_MASS_CHANGE_IFLOT, этой функции еще не существует, это ваше пользовательское имя функции, которую будет вызывать транзакция MASS, для физического изменения технических мест в базе данных. О реализации функции будет рассказано ниже. Пока просто «придумаем» имя, правила наименования пользовательских объектов разработки стандартные, я назвал функциональный модуль, начиная с буквы Y_. Сохраним данные: система запросит имя транспорта для переноса. Создадим запрос, в который будем записывать, как данные настройки, так и программный код, который создадим позже.

Если теперь зайти в транзакцию MASS, то на первом экране в списке выбора появится наш объект ведения данных для технических мест. Правда пока ничего еще не работает, так что, переходить к ведению данных еще рано, хотя если и перейти, то закладки выбора данных будут пустыми. Как видим, объект уже выбирается и транзакция MASS, что-то уже об этом объекте знает, Рис. 4: MASS-04.png.

Рис 4. MASS-04.png: транзакция MASS

2. Определение изменяемых таблиц и полей

Теперь добавим имена таблиц и полей, которые можно будет изменять в транзакции MASS. В общем виде можно указать все таблицы, в которых хранятся данные технических места, например, это таблицы IFLOT, ILOA и другие, а затем перечислить все поля этих таблиц. Однако нужно понимать, что фактически система не даст изменить все поля технического места. Если вы зайдёте в транзакцию изменения технических мест IL02, то сможете определить: какие поля можно менять, а какие закрыты от изменений, (например, код технического места и код балансовой единицы, изменить нельзя).

Мы будем добавлять для возможности использования в транзакции MASS таблицу IFLOT и следующие поля этой таблицы:

MAPAR – Номер детали производителя

IWERK – Завод, планирующий ТОРО

EQART – Вид технического объекта

INVNR – Инвентарный номер

GROES – Величина/размер

BRGEW – Вес брутто

GEWEI – Единица измерения веса

ANSDT – Дата покупки

SERGE – Серийный номер изготовителя

Есть несколько вариантов определения возможности изменения данных транзакцией MASS. Первый вариант: перечислить таблицы и поля в «ручном режиме»; второй вариант: указать «использовать все поля», а затем написать специальный функциональный модуль, который удалит из полного списка те поля, которые нельзя изменять; третий вариант: сделать структуру/ракурс, в который включить только поля, разрешенные для изменения. Какой вариант выбрать? Если предполагается разрешить пользователю для изменения 2 – 5 полей из 59, которые есть в таблице IFLOT, тогда, вероятно, проще выбрать вариант 1 или вариант 3. Если - 50 полей из 59, то вариант 2 будет оптимальным, т.е. даем изменять все поля, и пишем модуль, который исключит из этого списка 9 полей, запрещенных к изменению.

Имена таблиц требуется задать в таблице MASSTAB, а поля, если нужно, в таблице MASSFLDLST. Если выбран вариант ведения 2, то для данной таблицы также есть ракурс ведения. Какие внести данные, можно легко определить: в таблице MASSFLDLST всего три поля. Для нашего примера предпочтителен вариант 3, т.е. необходимо создать ракурс ведения таблицы IFLOT, в который включить только разрешённые к изменениям поля, перечисленные выше. Как было сказано, для задания значений у таблиц существуют ракурсы ведения, с такими же точно именами, как и у таблиц.

Итак, сначала идем в создание ракурса ведения для таблицы IFLOT, транзакция SE11 - создать ракурс. Создаём ракурс YTSH_IFLOTSTRUCT – Ведение технических мест для транзакции MASS - ракурс только для чтения таблицы IFLOT, Рис. 5: MASS-05.png. Кроме полей, предназначенных для изменения в транзакции MASS, в ракурс требуется включить также ключевые поля таблицы IFLOT.

Рис 5. MASS-05.png: ракурс YTSH_IFLOTSTRUCT

Теперь укажем этот ракурс в таблице MASSTAB через транзакцию ведения SM30. Тип объекта укажем BUS0010, который мы выбрали ранее. В поле имя таблицы зададим имя ракурса YTSH_IFLOTSTRUCT. Далее в поле «Число» укажем, например, значение 10. Данное поле служит для упорядочивания списка таблиц: если, например, таблиц/сегментов для обновления больше одной (что в нашем примере неактуально, так как у нас всего одна таблица). В поле «Таб БД» укажем имя таблицы базы данных, из которой фактически будет идти выборка. Для чего требуется указать имя таблицы в колонке «Таб. БД»? Суть заключается в следующем: в поле «Таблица» задаём имя структуры, содержащей только поля, разрешенные для изменения, которые и предложит транзакция MASS для выбора пользователю.

Однако часто ситуация заключается в том, что, например, мы разрешаем изменять поле «Серийный номер», при этом критерием выбора записей для обработки, в которых будет изменяться, является значение поля «Вид технического места», при этом не должно быть разрешено изменять это поле. Мы задали имя основной таблицы базы данных - IFLOT, что служит для транзакции MASS командой предложить пользователю все поля этой таблицы на селекционном экране выбора записей, которые предполагается изменить. Если выборка данных должна выполняться как-то особенно, то в поле «ФМ выбора», нужно задать имя функционального модуля выполняющего выборку данных. В общем случае достаточно стандартных функций выбора данных. И последнее, поле «Без нов. сегментов», в котором поставлена галка, представляет чек-бокса определяющий то, что транзакция MASS позволяет не только изменять данные, но и массово создавать новые данные. В рассматриваемом примере создание новых записей технических мест рассматриваться не будет, по этому мы отключили закладку создания новых технических мест (так как не будем использовать эту функциональность). Пример создания записи, Рис. 6: MASS-06.png.

Рис 6. MASS-06.png: Пример создания записи

Теперь, если перейти в транзакцию MASS, то картина будет более интересной, Рис. 7, MASS-07.png. Как видим, теперь транзакция MASS знает нашу структуру и поля, которые мы хотим разрешить изменять. Кроме этого программа уже умеет искать поля, используя кнопки поиска (справа от списка полей). Поиск может идти как по названию, так и техническому имени поля. Конечно, в данном случае, это не очень важно, так как набор полей для изменения ограничен, однако, если полей в списке много, то такая возможность не является лишней.

Рис 7. MASS-07.png: Транзакция MASS

Фактически, в данный момент мы должны выбрать нашу таблицу, она одна в списке и выбрать поля которые хотим изменить: можно выбрать как весь набор полей, так и отдельные поля, например, пусть это будет поле «Планирующий завод» и «Дата покупки». Для выбора выделим эти поля в таблице, нажав кнопки выбора слева от каждого поля, после чего можно нажать кнопку выполнить вверху экрана, Рис. 8: MASS-08.png.

Рис 8. MASS-08.png: транзакция MASS, выбор полей для изменения

Транзакция перейдет к экрану выбора технических мест, которые мы хотим изменить. Фактически, это уже описание работы с транзакцией MASS. По умолчанию, выбор предполагается по ключевым полям, в данном случае – это поле кодов технических мест. Однако транзакция MASS разрешает сделать выбор данных по любым полям, которые есть в таблице IFLOT, так как мы задали именно эту таблицу в настройке выше. Добавим на экран выбора поля: «планирующий завод» и «тип технического места», Рис. 9: MASS-09.png.

Затем укажем – выбрать все технические места, у которых не задан планирующий завод, после чего нажмём F8 – выполнить выбор данных. Система сообщит, сколько записей попадают под указанные критерии и предложит: или перейти к обработке изменений в диалоге, или выполнить фоновое изменение данных, используя создание варианта выполнения. В данный момент мы будем выполнять все операции в диалоговом режиме, поэтому выберем кнопку «Просмотреть все записи». В тестовой системе было выбрано 127 записей без присвоенного планирующего завода.

Рис 9. MASS-09.png: транзакция MASS, выбор полей для изменения

Описание работы с транзакцией MASS выходит за рамки данной статьи, поэтому, что и как можно задавать на экране ввода значений определяйте экспериментальным путем или прочитайте статью, на которую была дана ссылка вначале (возможно, что-то найдется в документации SAP). В примере мы задали «установить завод 1000», а для формирования серийного номера изготовителя задали кодировку на языке ABAP, т.е. фактически там идет генерация GUID-а, после чего нажал кнопку  – копирования значений в поля и система показала какими значениями, будет выполнено заполнение полей, Рис. 10: MASS-10.png.

Рис 10. MASS-10.png

Как видим, для поля серийного номера изготовителя были сгенерированы уникальные серийные номера. Пример подпрограммы кодировки для генерации внешних серийных номеров для транзакции MASS следующий (система сама генерируют заголовок подпрограммы):

Для обновления данных следует нажать кнопку сохранения результата. Однако пока еще не готова реализация собственно самого функционального модуля Y_TSH_MASS_CHANGE_IFLOT, который выполнит обновление данных на основании заполненных пользователями критериям. Фактически, не более чем за 15-20 минут мы создали диалоговую транзакцию для массового изменения необходимых нам данных с гибким вводом. Реализация, функции изменения данных объекта, будет рассмотрена ниже.

3. Настройка журнала обработки данных

Все сообщения, возникшие в ходе обновления данных, должны быть записаны в журнал обработки данных (далее журнал) и затем транзакция MASS покажет для каждой записи статус обновления или любую другую информацию, которая будет записана в журнал. Поэтому надо настроить наш бизнес-объект на управление журналом. Журнал настраивается с помощью ракурса ведения V_BALSUB – Журнал приложений: ракурс для ведения подобъектов. Для этого через транзакцию SM30 выполним ведение ракурса, появится экран запроса рабочей области, Рис. 11: MASS-11.png.

Рис 11. MASS-11.png: транзакция SM30 – экран запроса рабочей области

Имя рабочей области MASS, как и у транзакции ведения данных, поэтому введем код области и перейдем на следующий экран ведения данных, где добавим новую запись, Рис. 12: MASS-12.png (нужно ввести только имя объекта и текст описания).

Рис 12. MASS-12.png: ввод имени объекта и текста описания

Сохраним значения в запрос, фактически еще одни шаг по настройке транзакции MASS выполнен.

4. Настройка операций просмотра данных журнала

Эта настройка необязательна, но если необходимо, чтобы массовое ведение выглядело как в стандарте, то её лучше сделать. Назначение настройки заключается в том, что она обеспечивает переход из журнала транзакции MASS в просмотр или изменение обрабатываемых объектов (в нашем примере - технических мест). Если данную настройку не сделать, то журнал обработки будет выглядеть следующим образом, Рис. 13: MASS-13.png.

Рис 13. MASS-13.png: вид журнала обработки без настройки

Мы видим на панели инструментов только кнопку просмотра подробного текста к сообщениям об обработке. На рисунке отображён результата попытки присвоить значение поля «завод», равное 1200, для двух объектов. Система не разрешила выполнить такую операцию и сообщила причину.

Перейдём к ведению ракурса MASSAPPEX, в который добавим имена двух функциональных модулей, один для просмотра данных объекта (технического места), а другой для изменения. Как только такие данные будут добавлены, транзакция MASS выведет на панели инструментов две кнопки, для просмотра и изменения объектов из журнала, Рис. 14: MASS-14.png.

Рис 14. MASS-14.png: ведение ракурса MASSAPPEX

В поле CHAR20 имена событий, которые можно выбрать. Имена функциональных модулей, как и в случае с модулем обновления данных, пока только задаем, а их реализация будет описана ниже. Сохраняем данные, если теперь выполнить запуск массового изменения, то в журнале обработки появятся две кнопки, просмотра и изменения обрабатываемых объектов, Рис. 15: MASS-15.png.

Рис 15. MASS-15.png: вид журнала обработки с настройкой

Примечание

Вы не сможете получить журнал обработки до реализации пункта «Реализация функции обновления данных Y_TSH_MASS_CHANGE_IFLOT», т.е. результаты обработки будут видны только после того, как будут написаны объявленные ранее функциональные модули изменения и просмотра объектов.

5. Настройка возможности тестового запуска массового обновления

Для возможности запуска транзакции MASS в тестовом режиме необходимо добавить событие «TEST_MODE_KNOWN», так как описано в предыдущем разделе, в ракурс ведения MASSAPPEX в имени функционального модуля необходимо указать *, Рис. 16: MASS-16.png. Данное событие, позволит запускать транзакцию массового изменения с признаком тестового режима. Описание параметров будет сделано ниже.

Рис 16. MASS-16.png: настройка тестового запуска

После добавления этого события, если перейти в режим обработки данных транзакции MASS, на экране обновления данных на панели инструментов появится кнопка запуска транзакции в тестовом режиме, Рис. 17: MASS-17.png.

Рис 17. MASS-17.png: режим обработки данных

Если выполнить транзакцию в тестовом режиме, то в журнале появится сообщение, что изменения не сохранены, Рис. 18: MASS-18.png. Необходимо всегда обращать внимание на режим запуска транзакции MASS: тестовый или продуктивный, в функции Y_TSH_MASS_CHANGE_IFLOT, когда будете выполнять ее реализацию.

Рис 18. MASS-18.png: выполнение транзакции в тестовом режиме

6. Реализация функции обновления данных Y_TSH_MASS_CHANGE_IFLOT

Для типов объектов «техническое место», начиная с версии системы 4.6, существует BAPI функция, которая позволяет изменять программно данные технического места: BAPI_FUNCLOC_CHANGE. Если до этого места особого знания языка ABAP не требовалось, то реализация данного пункта невозможна без знаний ABAP, так как функция Y_TSH_MASS_CHANGE_IFLOT будет являться окаймляющей функцией вокруг стандартной BAPI. Параметры этой функции должны быть заданы по определенной маске, так как её вызов происходит динамически транзакций MASS для каждой записи отмеченной в этой транзакции для обработки.

На Рис. 19: FNMASS-01.png представлены входные и выходные параметры функционального модуля Y_TSH_MASS_CHANGE_IFLOT, который надо создать.

Рис 19. FNMASS-01.png: входные и выходные параметры функционального модуля Y_TSH_MASS_CHANGE_IFLOT

Внимание

Обратите внимание на то, что имена параметров и типы должны быть заданы в таком же виде, как показано на Рис. 20: FNMASS-01.png, кроме закладки «Таблицы», правила формирования имен которой, будут описаны отдельно.

• SELDATA – Таблица, содержащая заголовок объекта и параметры обработки, с которым работает транзакция MASS. Тип переменной MASS_TABDATA. Таблица должна быть отмечена как переменные значения, чек-бокс в соответствующей колонке.
• TESTMODE – Параметр, определяющий вариант выполнения транзакции MASS, если в данном поле стоит значение «X», значит выполнение запущено в тестовом режиме и вам не нужно выполнять COMMIT WORK, в противном случае, требуется выполнить изменения так как это продуктивный прогон операции. Тип параметра XFELD.
• MSG – Таблица сообщений, в которую вы должны вернуть для каждой обрабатываемой строки результат обработки. Данные этой таблицы будут выведены как журнал выполнения изменений. Тип параметра MASS_MSGS. При задании данного типа, система скажет, что пул типов не включен в группу функций. Для решения этой проблемы перейдите в TOP-инклуд группы функций, в которой вы создаете функциональный модуль и вставьте там строку, которая определяет общий пул типов транзакции MASS:
TYPE-POOLS: mass.
• Таблица SYTSH_IFLOTSTRUCT – Имя таблицы, в которую система передаст данные с экрана изменений транзакции MASS. Имя данной переменной должно быть сформировано по следующей маске S + <Имя таблицы/ракурса заданного при формировании сегментов из MASSTAB-TABNAME>, в данном случае это будет имя созданного ракурса, который содержит все поля, разрешенные к изменениям, ну а тип переменной будет это имя нашего ракурса. Если таблиц с полями для изменений было определено несколько, то они должны быть все перечислены на закладке таблиц с параметром – «не обязательно» в соответствующей колонке.

Сам текст функционального модуля, реализующего обновление технических мест, представлен ниже. Обратите внимание на параметры заполнения журнала транзакции MASS, особенно на формирование ключа объекта. В данном случае ключ формируется очень просто, так как это код технического места. Например, если бы это были изменения карточек ОС, то там ключ объекта должен был бы быть как соединение трех полей: <Код БЕ> + <Номер карточки ОС> + <Субномер карточки ОС>, т.е. ключ должен однозначно определять обрабатываемую запись.

7. Реализация функций просмотра и изменения объектов из журнала обработки

Переменная журнала ls_msg-objkey должна содержать ключ обрабатываемого объекта. В дальнейшем, при вызове функций просмотра или изменения этот ключ будет передаваться в заданные вами функциональные модули, чтобы вы смогли перейти к выдранному пользователем объекту. Для просмотра объекта мы объявляли функцию Y_TSH_MASS_VIEW_IFLOT, Рис. 20: FNMASS-02.png

Рис 20. FNMASS-02.png

Сам текст модуля очень простой:

Аналогично выполняется объявление функционального модуля для изменений обрабатываемых объектов Y_TSH_MASS_EDIT_IFLOT, Рис. 21: FNMASS-03.png

Рис 21. FNMASS-03.png

Текст функционального модуля практически такой же, как и при просмотре, отличается только код транзакции:

Итак, фактически за три часа рабочего времени была создана настройка и разработка для массового изменения технических мест, при этом, если нужно добавить какие-то дополнительные поля для обработки, то их просто нужно внести в ракурс ведения YTSH_IFLOTSTRUCT, конечно при условии, что эти переменные находятся только в таблице IFLOT. Функциональный модуль изменения технических мест, написан так, что корректно будет обрабатывать такие добавления.

Извините конечно, а в чем революционность данной технологии? Все загнали в память, добились устойчивости работы оборудования и? Так вы знаете лет 20 или около того, назад когда DOS был маленький, а памяти стало много, ее под RAM-диски стали отдавать и знаете компилировалось там все очень быстро, одна проблема была если это все вдруг зависало, то становилось чуть обидно за прошедшие час или два. А так, ну стало у вас сейчас памяти много, надежность работы выше, поэтому не страшно там базу держать и что? Революционность то в чем? Что-то принципиально новое придумали? Скорость выше? Так в памяти же все держите...

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

Путаница, связанная c терминологией SAP HANA продолжается давно. SAP HANA – это высокопроизводительный аппаратно-программный комплекс (High-Performance ANalytical Appliance), состоящий из двух частей аппаратной и программной. Программная часть это In-Memory СУБД. Аппаратная часть – севера с процессорами Intel Nehalem EX, работающие под управлением операционной системы SUSE Linux Enterprise Server SP01. Каждый поставщик аппаратного обеспечения имеет в своем арсенале линейку конфигураций позволяющий выбрать решение подходящее под требования заказчика. Основной критерий выбора – количество оперативной памяти, в ней должна размещаться все объекты In-Memory СУБД. Изначально были доступны конфигурации только на отдельных серверах, что требовало от заказчика уже использующего решение SAP NetWeaver BWA дополнительных инвестиций в аппаратное обеспечение, в случае перехода к SAP HANA. Сейчас часть поставщиков предлагают решения SAP HANA базирующиеся на серверах-лезвиях.

Платформа IBM eX5 Systems имеет чрезвычайно высокие показатели надежности. На основе постоянного анализа работоспособности оборудования существует возможность предотвращения сбоев. Если обнаруживается возможность выхода из строя какого-либо компонента, выдается сообщение, на основании которого можно отправить заявку в сервисный департамент IBM и заменить оборудование еще до выхода оборудования из строя. Также можно настроить отправку заявок в сервисный департамент IBM автоматически. В механизм предсказания сбоев помимо таких компонент системы, как жесткие диски, процессоры и память, включены также вентиляторы, VRM и блоки питания.

Нужно отметить, что SAP HANA не просто альтернатива другим СУБД в случае ее использования в качестве основной СУБД для SAP NetWeaver BW (SAP BW). Это качественный шаг вперед в том, что это первое решение переносящие часть операции обработки данных с уровня сервера приложений SAP NetWeaver WebAS ABAP на уровень СУБД. Примером приложения использующего такой подход является Planning Application Kit (PAK). Использование этого приложения позволяет существенно ускорить работу приложений бизнес планирования построенных на основе решений BW Integrated Planning и BusinessObjects Planning and Consolidation for SAP NW. Так же SAP HANA позволяет использовать в SAP BW новые схемы физического хранения объектов хранилища данных. Например у инфокуба оптимизированного для использования SAP HANA отсутствуют промежуточные таблицы измерений, что снижает требования к используемой памяти и упрощает обработку аналитических запросов. Оптимизированная для In-Memory структура DSO позволяет выполнять процесс активации или отката информационного пакета непосредственно на уровне СУБД, что позволяет отказаться от передачи данных с уровня СУБД на уровень сервера приложений SAP BW и ведет к существенному сокращению времени требуемого для выполнения этих операций с нескольких часов до минут.

Инструменты построения отчетности и визуализации SAP BusinessObjects и управления данными SAP BusinessObjects Data Services, включены в некоторые модели лицензирования SAP HANA.

Критерии автора при выборе двух технологий SAP BWA и SAP HANA следует использовать осмотрительно. Вот некоторые несколько примеров которые могут склонить чашу весов как в пользу одного так и другого решения. Как уже отмечалось ранее, на текущий момент доступны аппаратные конфигурации для SAP HANA использующие сервера лезвия, что позволит сократить инвестиции в аппаратное обеспечение. Кроме этого внедрение SAP HANA за счет хорошего сжатия данных высвободит ресурсы, используемые для хранения файлов данных СУБД других поставщиков. Внедрение BWA сокращает время загрузки данных и их доступности в отчетах за счет отсутствия необходимости создания традиционных агрегатов SAP BW. В версии SAP BW 7.3 есть возможность создавать инфокубы с постоянным хранением в BWA , в этом случае нет дублирования данных, т.к. таблица фактов не хранится на уровне традиционных СУБД. Если необходимо ускорение загрузки данных в DSO, альтернативы SAP HANA нет. Вывод один будущее однозначно принадлежит SAP HANA, но в настоящий момент для принятия решения о переходе необходимо считать полную стоимость владения SAP BW до и после перехода на SAP HANA.

Документационная поддержка бизнес-процессов, безусловно, является одним из важных вопросов, возникающих при внедрении ERP-системы. Практически на каждом проекте внедрения мы сталкиваемся с этой задачей. По моему опыту, в случае, когда основным внедряемым функционалом являются процессы FI и MM/SD, в первую очередь возникает задача хранения оригиналов и отслеживания статусов закупочных и сбытовых договоров, а также первичных бухгалтерских документов. В ситуации, когда автоматизируем процессы ТОРО, возникает вопрос структурированного хранения проектной и эксплуатационной документации с привязкой к техническим местам в SAP.

В течение долгого времени модуль SAP DMS являлся самым «правильным» инструментом для решения этих задач, и на наших проектах для решения первоочередной задачи по управлению договорами в SAP мы применяли с 2003 г. именно его. В то же время стоит помнить о сложностях, которые несет такое «частичное» решение задачи документационной поддержки.

Давайте рассмотрим пример с управлением договорными документами. Если мы организовываем процесс хранения и отслеживания исполнения договоров в SAP DMS, то необходимо также подумать о процессе подготовки и согласования договоров – в какой системе будет проходить он? Кроме того, договор, хранящийся в SAP DMS, также востребован в других существующих на предприятии системах. Например, договоры по производственным проектам, очевидно, должны быть доступны в составе проектной документации в системе управления проектами.

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

При этом компромиссные решения принципиально проблему не решают. Относительно примера с управлением договорами мы в наших проектах чаще всего приходили к варианту – автоматизировать подготовку и согласование договоров в отдельной системе управленческого (обще-распорядительного) документооборота, разработав при этом интерфейсы, обеспечивающие синхронизацию данных между SAP DMS и внешней системой документооборота. Но, даже не рассматривая трудоемкость создания и сопровождения таких интерфейсов, можно видеть, что проблема возникает повторно, как только возникает третья (четвертая, пятая, …) система, которой нужно обращаться к этому же договору.

Таким образом, как только мы начинаем использовать SAP DMS для обеспечения документационной поддержки отдельного бизнес-процесса, мы понимаем, что самым эффективным было бы реализовать в DMS управление всеми документами предприятия. В некоторых крупных российских компаниях такая задача была успешно решена, но это, к сожалению, на общем фоне можно считать скорее исключением, чем общей тенденцией. Общепризнанной особенностью российского документооборота является жесткая регламентированность процессов согласования документов. Даже специализированные системы документооборота далеко не всегда могут «из коробки» предоставить такие возможности как параллельно-последовательное согласование, нормирование сроков согласования в зависимости от объема документа (с учетом производственного календаря рабочих и праздничных дней), согласование «по умолчанию», механизмы посредников, делегирование полномочий, и т.д. Когда мы начинаем реализовывать все перечисленные особенности с помощью ABAP-разработок в DMS, это сразу же утяжеляет решение и значительно увеличивает сроки и бюджет внедрения. Кроме того, как многие столкнулись на практике, использование механизмов классификации SAP для создания дополнительных атрибутов документов, может в дальнейшем вызывать сложности в построении отчетов. Механизм классификации привлекает своей универсальностью, но оборотной стороной универсальности является более сложная и менее читаемая структура хранения данных (по сравнению со стандартными таблицами других модулей).

Поэтому 2 года назад, когда у SAP появился продукт SAP Extended ECM, его появление вызвало огромный интерес и вопросы – сможет ли он более широко и эффективно решить задачу управления документами? К настоящему времени, когда сразу несколько крупных российских компаний завершают проекты его внедрения, можно сделать выводы, что Extended ECM и его основной модуль Content Server позволяют реализовать эффективную систему управления контентом предприятия и организовать доступ к документам из различных транзакций SAP ERP. В качестве одного из примеров таких компаний можно привести ЛУКОЙЛ Оверсиз Холдинг Лтд, где с помощью Content Server реализован как управленческий, так и производственно-технический документооборот.

Соглашаясь с описанными в статье сильными сторонами SAP DMS, для условий российского документооборота я бы предложил рассматривать более широкий функционал SAP Extended ECM.

Огромное спасибо всем за проявленный интерес. Особенно хочется отметить Артема Седловского, объем и содержание комментария, оставленного им, говорит сам за себя.
Поднятые вами открытые вопросы можно распределить по следующим группам: интеграция и риски, связанные с потенциальной сменой технологии; функционал SAP EHS и «локализация»; использование продукта SAP EHS в России и СНГ.
Предлагаю начать с первой - интеграция и риски, связанные с потенциальной сменой технологии. Наличие системы (условно - HR), сопровождающей хозяйственную деятельность отдела управления кадровым потенциалом компании в отдельном ландшафте от системы (условно - ERP), сопровождающей основную хозяйственную деятельность, включая ее финансовую составляющую, весьма типично по ряду причин. И, например, вопрос о том, как передать рассчитанную в системе HR зарплату сотрудника в финансовый блок системы ERP, с целью провести соответствующую бухгалтерскую проводку, ограничивается лишь только возможностями одной и другой систем. Если мы говорим о SAP системах, то они обладают возможностью общаться друг с другом, или другими системами, за счет технологий EDI и ALE. Вопрос выбора зависит от конкретного сценария. Не исключена возможность использования интеграционной шины – SAP XI (PI). Если сценарий подразумевает, что модуль EHS настроен в системе SAP ERP, а HR система – это изолированная SAP HR, то данные из HR рекомендуется получать, используя  технологию ALE посредством iDOC за счет RFC.  Продолжая тему технологий, и связанных с их обновлениями рисками, следует сказать, что ИТ система, будь то ERP или MES воспринимается нашими иностранными коллегами, как обязательное оборудование, необходимое для ведения бизнеса и дающее свой вклад в капитализацию предприятия. А раз это оборудование, то к нему применимы понятия: обслуживание и модернизация. Отсюда вопрос о переходе на лучшую технологию лишь упирается в необходимость, а обслуживание – в компетенцию сервисной организации, обслуживающей ИТ систему. Возвращаясь к примеру с Environment Compliance на java, имеет смысл отметить, что, во-первых это не первый продукт SAP на java; во вторых, EHS, как таковой, также является продуктом TechniData; в третьих, “E” действительно означает Environment  - понятие, которое не ограничивается одними только «выбросами», и в случае с EHS, больше связано с регулированием воздействия на окружающую среду химических веществ, входящих, например, в состав сырья или продукта.  Отдельно следует сказать, что продукт Environment Compliance был специально разработан, как отельный и самодостаточный инструмент, решающий задачи охраны окружающей среды, что дает возможность развертывать его независимо и гибко вписывать его в КИС предприятия.  Решение задач охраны окружающей среды с помощью SAP будет освещено в следующем посте.  
Теперь предлагаю перейти ко второй группе - функционал SAP EHS и «локализация». Стандартный функционал EHS способен решить задачу фиксации инцидентов и нарушений и обладает инструментарием для аттестации рабочих мест, но этим не ограничивается. Для раскрытия вопроса относительно «локализации» вполне резонно  вначале определить, что скрывается под этим термином. Если мы говорим о локальных требованиях, предъявляемых к продуктам SAP, как к софту, то SAP имеет все необходимые лицензии. Если мы говорим о русскоязычном интерфейсе, то SAP в целом и модуль EHS в частности имеют таковой и поддерживают кириллицу. Если мы говорим о специфической функциональности, которая присуща только России и странам СНГ, как например специфика налогового учета, то, поговорив со специалистами ОТ и ПБ, просмотрев стандарты безопасности труда,  такие как OHSAS 18 серии, ГОСТ 12.0.230-2007, становится ясно, что принципиальной разницы в подходах нет и, требования к функциональности схожи. Если же мы говорим о контенте – справочниках или основных (master) данных, выходных печатных формах и т.п., о чем упоминается в одном из комментариев, то модуль EHS входит в SAP ECC 6.0 и система в целом обладает необходимым стандартным инструментарием для его создания. Тем не менее, работы над разработкой дополнения, включающего в себя «российский» контент ведутся SAP совместно с партнёром. Результаты будут освещены в этой колонке позже. Однако следует отметить, что работа по созданию контента стоит перед любым интегратором SAP EHS во время проекта внедрения в любой стране мира и считается типовой и ни кого она не удивляет и не останавливает.
И наконец, третья группа -  использование продукта SAP EHS в России и СНГ. Здесь, могу сказать, что на текущий момент есть несколько проектов в России находящихся в различных стадиях. Один из них - успешно завершен одним из российских партнеров. Могу сказать, что партнер столкнулся с вопросами, уже озвученными выше, а именно интеграция, «локализация», возможности функционала и успешно справился с ними в рамках заявленной цели проекта. Не корректно будет отнимать лавры успеха у партнёра, целесообразнее будет предоставить ему самому рассказать о них. Уверен, что партнер готов поделиться опытом и возможно, кто-то из вас уже посещал WebEx, проводимый одним из специалистов этого партнера на эту тему.  По известным причинам ни партнера, ни клиента называть не буду, тем не менее, при обращении в частном порядке готов раскрыть эту информацию и посодействовать в коммуникации с ним.

Поздравляю с выходом сигнального номера журнала. Желаю успехов и насыщенного контента. Отличная инициатива. Опыт профессионалов всегда будет интересен.

Александр.
Вы задаёте совершенно правильные вопросы. И моя позиция не на стороне банков и не на стороне вендора. Я озвучил лишь свои личные выводы.
1. Грядет ВТО, глобализация, акционирование, смена собственников. Иностранные системы - это неизбежность. Моё внутреннее ощущение, что локальные банковские решения идеологически отстали на 7-10 лет. Некоторые системы только недавно реализовали SOA архитектуру или перешли к сделочной модели. В большинстве своём, местные АБС стараются следовать за регулятором, а не за общемировыми практиками.
2. Как я понял из общения во время форума, требования 2332-У по отчетности SAP готов отдать на откуп локальным партнерам, которые имеют методологию и наработки. И они же будут реагировать на указания ЦБ, "актуальные со вчерашнего дня".  Сам же SAP сконцентрирован на продаже высокопроизводительных решений типа SAP HANA, решений по управлению рисками, лимитами, на транзакционной системе. То, что будет востребовано во всем мире.
3. И здесь согласен с Вами. Каждый банк уникален. Есть хорошие и современные, а есть те, где exсel - главный инструмент. Где-то моносистема, а где-то "зоопарк" из систем. И где-то владельцы могут прийти к решению не обновить российскую АБС на новую версию, а внедрить продукт другого уровня. SAP - всё таки больше бренд. И бренд продаваемый. И то, что у банка хватило сил и ресурсов, чтобы внедрить такой продукт, уже покажет уровень и качество менеджмента.
Я надеюсь, что к этой дискуссии присоединятся представители самого вендора и исправят некоторые заблуждения.

В процессе изменения мировоззрения вижу два драйвера. Первый - это заявленный локальным регулятором - Центральным банком постепенный переход на МСФО. Это изменит подход к учёту и отчетности во всех банковских решениях.
Второй - потребность в капитализации и подготовка к IPO ряда банков. К отчетности, предоставляемой иностранным акционерам будут предъявляться международные требования и стандарты. И здесь внедрение новых продуктов, смена учётной политики неизбежна.

Спасибо большое! Очень полезная статья

интересная статья, к сожалению приходится сталкиваться с подобными "казусами"

Интересный обзор. И выводы тоже интересные, хотя и вызывают некоторые вопросы:
 
1. Что Вы имеете ввиду под готовностью рынка к новым продуктам? Проявления интереса к новым технологическим решениям и системам со стороны потенциальных заказчиков? Так эти проявления были практически всегда, и тема "заменить АБС nnnn на АБС хххх ", наверное, может быть отнесена к разряду вечных. Или появились какие-то более значимые основания, позволяющие говорить о возросших рыночных перспективах зарубежных вендоров класса SAP?
 
2. А еще, наверное, будут вопросы про поддержку и адаптацию системы к указаниям ЦБ, которые вводятся "с момента получения настоящего письма". Как правило, эти вопросы сводятся к одному: "Через сколько времени Вы можете это сделать?". Интересно, как с этой точки зрения будет выглядеть решение от SAP по сравнению с системами местного производства.
 
3. В банке, в том числе и в российском,  много разных специалистов и все они решают разные задачи, используя при этом разные понятия и категории. Для каких-то задач счета бухгалтерского учета - самый подходящий инструмент (в отчетности РСБУ куда  же без них!), а для каких-то более естественным выглядит использование понятий "сделка" или "бизнес-операция". О какой же ломке стереотипов идет речь? Ведь в АБС российских вендоров давно и успешно используются как модель основанная на счетах бухгалтерского учета, так и сделочная модель.

Владимир. После прочтения колонки осталось ощущение недосказанности. Цитирую второй абзац "Однако на российском рынке все еще велик процент компаний, в которых к аппаратной платформе относятся не как к источнику прибыли, а как к расходной части". Кажется, что следующей мыслью должно быть описание того, какой value от покупки правильного железа получат компании. Дорогое железо - это несомненно расходы. И железо - это всего лишь малая составляющая прибыли компании. Мощное железо ничего не гарантирует.
Далее у Вас следует многословное описание, что для каждой задачи необходимо покупать подходящее железо. Но нигде нет про дополнительные преимущества, которые получит бизнес от решений именно от IBM. В том же премиум классе автомобилей также есть выбор. И чтобы проехаться на хорошем автомобиле не обязательно его покупать - есть сервисы проката, что аналогично аренде вычислительных мощностей.

Хорошая, годная сэйловая статья. Однако, как обычно остаются вопросы, традиционные практически для каждого компонента САП:
Локализация:
1. Какие справочники, установленные российским (украинским, белорусским - кому что надо) законодательством локализованы? Шум, радиация, вибрация, ... - хоть что-то из нашего Р 2.2.2006-05? Структура справочников, источники данных, договоренность САП СНГ с источниками данных о платности/бесплатности?
2. Какие законодательно установленные формы учета локализованы?
3. Какие отчетные статформы локализованы?
4. Какая документация доступна на русском языке на тему локализации?
Технические вопросы:
5. Как все описанное связано с темой спецодежды, о локализации которой заявлено в EhP6? 6. Как вендор рекомендует выполнять интеграцию, когда основная финансово-производственная система - одна SAP ERP, а кадровая - хотя бы в выделенном ландшафте SAP HR, не говоря уже о том что это может быть Peoplesoft, Scala или еще что?
Стратегические планы:
7. До недавнего времени буковка Е в аббревиатуре EHS означала Энвайромент и там были красивые презентации про выбросы. Пару лет назад SAP купил компанию Technidata с продуктом Emission and Compliance и квадратики про выбросы теперь показываются про продукт SAP ЕС. Это совсем отдельная инстанция отдельного софта на технологии java, с покупкой которой САП отменил все планы развития темы выбросов на АВАР-движке. В связи с этим возникает вопрос: на сколько лет вперед заказчики могут быть уверены, что бизнес-тема охраны труда или промбезопасности не уплывет в какую-нибудь вновь приобретенную технологию? В этом случае на локализации АВАР-функциональности САП СНГ сразу поставит крест, прикладную область Охраны Труда и Промышленной Безопасности каждому клиенту придется поддерживать на АВАР самостоятельно.
 
Полагаю, эти вопросы будет задавать любой российский заказчик, решивший на САПе решать тему Охраны Труда и Промышленной Безопасности.
 
С уважением,
Артем Седловский

Появились ли какие-либо действующие и потенциальные проекты на территории не только России, но и всего СНГ? Возможно западные клиенты, готовые сотрудничать с нашими специалистами?

Интересная статья, но верните изображения. Ни одной картинки нет.

В стандартном EHS есть функционал для фиксирование инцидентов и нарушений, инструментарий для аттестации рабочих мест ?
 
Какие конкретные предприятия можно назвать в России с эффективным внедрением и применением EHS для Охраны Труда и Промышленной Безопасности ?

Инициатива верстальщика:
- во-первых, так ему удобнее (верстать меньше)
- во-вторых, те, кому надо, помучаются (а что может быть приятнее для русского человека, когда другие мучаются, используя результаты его труда?!)
-  в-третьих, халявщики всякие читать меньше будут
....
 
P.S. В ближайшее время будет исправлено.

А текст программы в виде картинки, это чтобы кому надо интеллектуально перебили это все себе?

---
Необходимо проводить обучения, презентовать мировые практики. Здесь специалисты мыслят категориями счетов. SAP построен на иной модели,
---
Ага а знаете во что это выльется? Сделают как и в ERP категории счетов и т.д. и назовут это решением для страны и на этом все и закончится. Потому что переучивать сложно и долго, а продать надо сейчас и быстро и в итоге в ERP имеем оборотно-сальдовые ведомости, корреспонденцию счетов и еще кучу всякой ерунды для тех кто мыслит категориями счетов и не собирается мыслить по другому.

Виталий, в наших статьях изложена методика внедрения по Теории ограничения. Другое дело, что "поллианнам" и "честным министрам" это не нужно...