Меню

Миграция на SAP HANA

Что такое HANA

SAP HANA гибкое, независимое от источника данных приложение, которое позволяет клиентам обрабатывать экстремально большие объемы данных в реальном времени, не прибегая к необходимости анализировать эти данные в дополнительных в отдельных системах.
Продукты SAP Business Suite, работающие с SAP HANA заново определяют понятие «скорость ведения бизнеса» и открывает новый мир возможностей. Клиенты теперь могут управлять такими критичными для них бизнес процессами как, планирование, реализацию, отчетность и анализ данных в реальном времени, используя оригинальные исходные данные. 

Зачем мигрировать

Реальность текущих бизнес сценариев выглядит таким образом, что большинство из них являются неоптимальными с точки зрения производительности.
В настоящее время традиционная IT инфраструктура не может полностью удовлетворять потребностям одновременно транзакционных и аналитических систем. Это соответственно ведет к тому, что в архитектуре систем делаются уступки, тем или иным образом компенсирующие слабые стороны. Традиционные архитектуры практически не позволяют сочетать транзакционные среды (продажа товаров, обслуживание заказов, сбор денег) и аналитические (н-р доходность от продаж в разрезе заказчика или, например, конкретного региона).

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

Транзакционная: «order to cash» является сквозным бизнес процессом. Его действие затрагивает многие отделы предприятия и требует данных из большого количества систем. В нашем случае данные о товарах и финансовые данные получаются из транзакционной системы. В нашем случае предполагается, что транзакционные данные используются в финансовой системе и в системе поставок. Компании могут создавать миллионы или даже миллиарды документов в день. Таким образом, автоматизированные системы должны иметь возможность обрабатывать и сохранять эти документы очень быстро. Каждый документ может быть достаточно простым по объему данных, которые в нем содержаться, но потенциально может потребоваться большому количеству людей или систем. При этом целостность данных является критичной, и эффективность работы процесса может играть важную роль в успешности жизнедеятельности предприятия.

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

Цель HANA – уменьшить сложность и стоимость, связанную с описанным выше примером, где делается деление на транзакционную и аналитическую часть путем объединения их в единое целое. Схема ниже показывает как HANA может обеспечить более простую среду для обеспечения работы того же бизнес процесса.

Основное преимущество заключается в том, что компании могут достигнуть экономии в нескольких областях:

  • Более низкая стоимость CPU
  • Более низкая стоимость хранения данных
  • Более низкая стоимость управления данными
  • Более низкая стоимость администрирования систем
  • Более низкая стоимость на владения базами данных
  • Более низкая стоимость на устройство сетей

Кроме чисто стоимостных выгод присутствует также тема более высокой производительности. HANA позволяет достичь ускорения обработки данных в сотни или даже тысячи раз.

Преимущества БД HANA.

Не вдаваясь в детали можно было бы выделить несколько потенциальных областей, в рамках которых можно было бы достигнуть потенциального повышения производительности БД и рассматривать HANA как потенциальную замену каким либо другим БД.

  • Самоиндексация – HANA сама строит индексы по таблицам. Таким образом, архитекторам и администраторам больше нет необходимости тратить время на создание, администрирование, анализ и оптимизацию индексов в схемах данных.
  • Высокая степень сжатия данных – HANA позволяет обеспечивать сжатие данных до 20 раз по сравнению с их оригинальным состоянием. Таким образом, при миграции 20 ТБ данных могут быть сжаты до 1 ТБ. Более того анализируются непосредственно сжатые данные. Все это позволяет сократить расходы на системы хранения данных и на вычислительные мощности.
  • Поколоночное хранение данных – нет необходимости в предварительном построении агрегатов, как следствие, можно достаточно легко анализировать временные последовательности. В данном случае можно привести аналогию с калькулятором с бесчисленным количеством функций. В тоже время традиционные аналитические системы можно сравнить с калькуляторами с 4мя или 5тью предопределенными функциями. В традиционных системах необходимо знать, что конкретно необходимо искать и делать прекалькуяцию для оптимизации времени отклика. В HANA таких требований нет и все типы анализа возможны фактически на лету.
  • Хранение данных в памяти – поскольку данные доступны мгновенно, возможны варианты очень быстрого анализа. Есть примеры, когда обработка данных в HANA происходила в 10000, а то и в 100000 раз быстрее.
  • Оборудование – HANA работает на процессорах х86 и оборудование может быть получено от IBM, HP, Cisco, EMC, Lenovo, Cisco, Fujitsu and Dell. В качестве операционной системы для СУБД используется открытая ОС Linux. Таким образом, достигается минимизация требований к ресурсам оборудования.

Консолидация транзакционных и аналитических данных

Данное преимущество будет ключевым для БД HANA. Объединение транзакционных и аналитических данных в едином хранилище, на едином оборудовании/сетевой инфраструктуре может кардинально уменьшить стоимость владения системой, одновременно увеличив и улучшив доступ, качество данных и производительность системы.

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

Планирование
Миграция на СУБД HANA требует тщательного и взвешенного подхода. Фактически миграцию на новую СУБД можно сравнить в некоторой степени с проектом апгрейда. В той степени, что проект будет содержать те же фазы и преследовать те же задачи, что и проект апгрейда.
В той же степени проект миграции можно сравнить с проектом апгрейда исходя из его длительности. Можно сказать, что в среднем для клиента проект может занять от трех до четырех месяцев. За это время клиент должен будет не только (и не столько) провести технические работы, но и провести тестирование, а также в каких-то случаях корректировку пользовательского кода или пользовательских расширений. Также как и в проектах апгрейда среднее соотношение между чисто техническими и условно прикладными работами будет близко к соотношению 20/80.

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

  • Функциональный архитектор для организации проведения тестирования и определения необходимых для тестирования бизнес процессов
  • Функциональные специалисты для проверки работоспособности бизнес процессов
  • Технический специалист с опытом проведения апгрейдов и гетерогенных миграций собственно для выполнения технических работ
  • Разработчики ABAP для корректировки пользовательских расширений и пользовательского кода
  • Бизнес пользователи для возможного участия в интеграционном тестировании
  • И, наконец, руководитель проекта для организации работы такой большой команды

С учетом всего вышесказанного основными этапами проекта будут:


Фаза подготовки


В рамках подготовки проекта необходимо будет решить следующие задачи.

  • Проработка архитектуры решения
  • Подготовка плана перехода на HANA
  • Оценка необходимого оборудования для последующей миграции на СУБД HANA
  • Проверка ЦОД на готовность к работе с СУБД HANA
  • Концептуальное проектирование

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев9

Комментарий от  

Олег Точенюк

  |  22 ноября 2013, 19:20

Была у какого-то сатирика миниатюра про не понимаю. Считайте этот комментарий из того же самого разряда, про я не понимаю:
 

Прикольно написано, особенно про даже не миллиард, а миллиарды документов в день, которые создаются даже не одной, а кучей компаний, ага это ~11574/сек. Про базу ничего не скажу, но в ERP большинство объектов нумерации документов это 10 символов, т.е. скажем так 100 дней и диапазон нумерации меняем, вместе с годом кстати. Дальше про структуру документа, которая должна быть очень простой, чтобы обеспечить максимально быстрое сохранение документа в базу данных, тут я не возражаю конечно, но до сих пор не пойму почему и с какого времени было решено что SAP ERP стала просто системой хранения документов? Т.е. вот это вот ERP - это оказывается просто хранение документов? Я так понимаю вы полностью солидарны с Муковозом Ильей Сергеевичем, который давно уже как я понимаю все начиная от баланса и заканчивая остатками хранит и ведет на BW системах, для чего у него даже специально выделенные BW-консультанты по сегментам вводятся в отдел поддержки. Занятно, лет уже 8-9 назад выбросили R/3 из названия продукта, сейчас решили похоже что про этот самый R, уже забыли все, поэтому встречайте новую реинкарнацию потерявшейся буквы R в виде не очень приятного в русском звучании названии -> HANA и... и тут снова какая-то непонятка, если HANA это СУБД, а драйвер/коннектор от/к SAP ERP уже написан и работает, то зачем нам теперь BW? Если на данных ERP мы получим ускорение, ну хорошо в 100 раз, т.е. отчет формирующийся на данный момент 1 сутки, без всяких вопросов, теперь будет формироваться 864 секунды, ну т.е. чуть меньше минут 15, ну вполне вменяемо как мне кажется или на BW оно вообще будет меньше секунды. Не быстро это хорошо, но охота посмотреть на того бойца который генерит отчетность со скоростью 1 отчет = 1 секунда и при этом как-то наверное еще умудряется понять что же в этом отчете написано, тоже наверное где-то внутри у него своя HANA стоит и коннектор работает.

Комментарий от  

Сергей Осин

  |  28 ноября 2013, 17:19

Была у какого-то сатирика миниатюра про не понимаю. Считайте этот комментарий из того же самого разряда, про я не понимаю:
 

Прикольно написано, особенно про даже не миллиард, а миллиарды документов в день, которые создаются даже не одной, а кучей компаний, ага это ~11574/сек. Про базу ничего не скажу, но в ERP большинство объектов нумерации документов это 10 символов, т.е. скажем так 100 дней и диапазон нумерации меняем, вместе с годом кстати. Дальше про структуру документа, которая должна быть очень простой, чтобы обеспечить максимально быстрое сохранение документа в базу данных, тут я не возражаю конечно, но до сих пор не пойму почему и с какого времени было решено что SAP ERP стала просто системой хранения документов? Т.е. вот это вот ERP - это оказывается просто хранение документов? Я так понимаю вы полностью солидарны с Муковозом Ильей Сергеевичем, который давно уже как я понимаю все начиная от баланса и заканчивая остатками хранит и ведет на BW системах, для чего у него даже специально выделенные BW-консультанты по сегментам вводятся в отдел поддержки. Занятно, лет уже 8-9 назад выбросили R/3 из названия продукта, сейчас решили похоже что про этот самый R, уже забыли все, поэтому встречайте новую реинкарнацию потерявшейся буквы R в виде не очень приятного в русском звучании названии -> HANA и... и тут снова какая-то непонятка, если HANA это СУБД, а драйвер/коннектор от/к SAP ERP уже написан и работает, то зачем нам теперь BW? Если на данных ERP мы получим ускорение, ну хорошо в 100 раз, т.е. отчет формирующийся на данный момент 1 сутки, без всяких вопросов, теперь будет формироваться 864 секунды, ну т.е. чуть меньше минут 15, ну вполне вменяемо как мне кажется или на BW оно вообще будет меньше секунды. Не быстро это хорошо, но охота посмотреть на того бойца который генерит отчетность со скоростью 1 отчет = 1 секунда и при этом как-то наверное еще умудряется понять что же в этом отчете написано, тоже наверное где-то внутри у него своя HANA стоит и коннектор работает.

Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, ERP можно с полной уверенностью считать таковой. В данном смысле модель работы SAP ERP системы, существовавшая до появления SAP HANA, в полной мере отвечала такой концепции, поскольку база данных в ней использовалась лишь как хранилище информации.
Напротив, в концепции, в которую включается SAP HANA как база данных, появляется возможность переносить отдельные элементы логики приложений на уровень базы данных и за счет этого повышать производительность транзакций и отчетов..
Если же мы имеем в виду бизнес-логику приложения ERP как таковую, то при миграции на SAP HANA она не изменится. Существует также возможность включать/выключать выполнение оптимизированной на SAP HANA логики стандартных прорамм/транзакций. Стоит также отметить, что в версию ERP для SAP HANA включены дополнительные преднастроенные приложения на базе технологии HTML5 (например, MRP Cockpit). Для процессов, построенных на пользовательских разработках, оптимизацию необходимо будет делать дополнительно.
Таким образом, в случае применения SAP HANA в качестве СУБД для SAP ERP, заказчик получает не только базу данных, позволяющую обрабатывать большие объемы данных с более высокой скоростью, нежели традиционные СУБД, но и платформу для построения новых приложений на основе процессов в ERP, позволяющих анализировать информацию в режиме реального времени. Это позволяет нам говорить о  возвращении к реальному значению термина «Real-time data processing». Причем речь идет не только об ускорении выполнения традиционных отчетов, но и о функциональности, которая считалась нереализуемой ранее из-за проблем с производительностью. Примером может являться сегментация клиентов в CRM приложениях для торговых организаций. Данный процесс в традиционной архитектуре требовал накопления информации и ее переноса в BW, а теперь может выполняться непосредственно в системе CRM.
Говоря про аналитические возможности, я хотел бы отметить, что как минимум в ближайшем обозримом будущем хранилища данных будут по-прежнему строиться на основе SAP BW, теперь использующем SAP HANA в качестве СУБД и платформы для построения real-time отчетности. Связано это в основном с тем, что в настоящее время решение SAP BW предоставляет огромный объем функциональности, позволяющей, к примеру, вести предварительную обработку данных, строить системы бюджетирования и консолидации, реализовывать концепцию data aging с помощью решения NLS. Вероятно, настанет момент, когда данная функциональность будет интегрирована в единую платформу для транзакционных и аналитических систем.
 
Сергей Осин

Комментарий от  

Олег Точенюк

  |  29 ноября 2013, 00:41

Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, ERP можно с полной уверенностью считать таковой. В данном смысле модель работы SAP ERP системы, существовавшая до появления SAP HANA, в полной мере отвечала такой концепции, поскольку база данных в ней использовалась лишь как хранилище информации.
Напротив, в концепции, в которую включается SAP HANA как база данных, появляется возможность переносить отдельные элементы логики приложений на уровень базы данных и за счет этого повышать производительность транзакций и отчетов..
Если же мы имеем в виду бизнес-логику приложения ERP как таковую, то при миграции на SAP HANA она не изменится. Существует также возможность включать/выключать выполнение оптимизированной на SAP HANA логики стандартных прорамм/транзакций. Стоит также отметить, что в версию ERP для SAP HANA включены дополнительные преднастроенные приложения на базе технологии HTML5 (например, MRP Cockpit). Для процессов, построенных на пользовательских разработках, оптимизацию необходимо будет делать дополнительно.
Таким образом, в случае применения SAP HANA в качестве СУБД для SAP ERP, заказчик получает не только базу данных, позволяющую обрабатывать большие объемы данных с более высокой скоростью, нежели традиционные СУБД, но и платформу для построения новых приложений на основе процессов в ERP, позволяющих анализировать информацию в режиме реального времени. Это позволяет нам говорить о  возвращении к реальному значению термина «Real-time data processing». Причем речь идет не только об ускорении выполнения традиционных отчетов, но и о функциональности, которая считалась нереализуемой ранее из-за проблем с производительностью. Примером может являться сегментация клиентов в CRM приложениях для торговых организаций. Данный процесс в традиционной архитектуре требовал накопления информации и ее переноса в BW, а теперь может выполняться непосредственно в системе CRM.
Говоря про аналитические возможности, я хотел бы отметить, что как минимум в ближайшем обозримом будущем хранилища данных будут по-прежнему строиться на основе SAP BW, теперь использующем SAP HANA в качестве СУБД и платформы для построения real-time отчетности. Связано это в основном с тем, что в настоящее время решение SAP BW предоставляет огромный объем функциональности, позволяющей, к примеру, вести предварительную обработку данных, строить системы бюджетирования и консолидации, реализовывать концепцию data aging с помощью решения NLS. Вероятно, настанет момент, когда данная функциональность будет интегрирована в единую платформу для транзакционных и аналитических систем.
 
Сергей Осин

Под термином документ я имел именно то что написали вы "Компании могут создавать миллионы или даже миллиарды документов в день", я так думаю мы с вами об одних и тех же документах подумали. Хотя если это не так, то уточните какие именно документы имели ввиду вы.
 
Я ничего не имею против СУБД HANA, но я не понял как изменится модель работы SAP ERP при переходе от СУБД Oracle к СУБД HANA? Мне кажется, что она останется такой же как и была, хотя нет, кое какие отчеты которые перегружались в BW можно будет выполнять теперь без проблем в SAP ERP. Что же касается красот использования хранимых процедур HANA, то я так понял SAP отказывается от переносимости кода между СУБД различных производителей и далее нас ждут реальные изменения синтаксиса ABAP-а. Ну знаю одного клиента, который в такой ситуации точно не купил бы SAP ERP на HANA, так как SAP ERP на MS SQL ему реально встала дешевле и ее ему пока хватает. И кому станет хорошо, когда эту возможность у него отберут? Наверное аксапте, с чем ее и поздравляю.
 
"Real-time data processing" - Еще больше замечательно, теперь как я понимаю в скором времени в SAP ECC скоро вернут потерявшуюся букву R и будет что-то типа SAP ECC RTDP.
 
Что касается CRM, тут я не силен, но эта функциональность всегда стояла кажется отдельно со своей базой и не входила никогда в состав SAP ERP? Но я конечно так же рад, что установка CRM на СУБД HANA и ей тоже очень помогла с производительностью.
 
Кстати, по поводу систем консолидации, я чего-то думал что за эту радость отвечает уже функциональность BPC. А ей вроде как ну будет там ниже стоять HANA, ну статистическому биписишнику придет счастье, в виде реального ускорения выполнения отчетов.
 
А да, еще по поводу платформы, я все считал что платформа у нас сап нетвьювер, а СУБД даже если она очень быстрая, платформой быть не может, она же уже СУБД и ничего больше.

Комментарий от  

Алексей Селин

  |  05 декабря 2013, 10:12

Под термином документ я имел именно то что написали вы "Компании могут создавать миллионы или даже миллиарды документов в день", я так думаю мы с вами об одних и тех же документах подумали. Хотя если это не так, то уточните какие именно документы имели ввиду вы.
 
Я ничего не имею против СУБД HANA, но я не понял как изменится модель работы SAP ERP при переходе от СУБД Oracle к СУБД HANA? Мне кажется, что она останется такой же как и была, хотя нет, кое какие отчеты которые перегружались в BW можно будет выполнять теперь без проблем в SAP ERP. Что же касается красот использования хранимых процедур HANA, то я так понял SAP отказывается от переносимости кода между СУБД различных производителей и далее нас ждут реальные изменения синтаксиса ABAP-а. Ну знаю одного клиента, который в такой ситуации точно не купил бы SAP ERP на HANA, так как SAP ERP на MS SQL ему реально встала дешевле и ее ему пока хватает. И кому станет хорошо, когда эту возможность у него отберут? Наверное аксапте, с чем ее и поздравляю.
 
"Real-time data processing" - Еще больше замечательно, теперь как я понимаю в скором времени в SAP ECC скоро вернут потерявшуюся букву R и будет что-то типа SAP ECC RTDP.
 
Что касается CRM, тут я не силен, но эта функциональность всегда стояла кажется отдельно со своей базой и не входила никогда в состав SAP ERP? Но я конечно так же рад, что установка CRM на СУБД HANA и ей тоже очень помогла с производительностью.
 
Кстати, по поводу систем консолидации, я чего-то думал что за эту радость отвечает уже функциональность BPC. А ей вроде как ну будет там ниже стоять HANA, ну статистическому биписишнику придет счастье, в виде реального ускорения выполнения отчетов.
 
А да, еще по поводу платформы, я все считал что платформа у нас сап нетвьювер, а СУБД даже если она очень быстрая, платформой быть не может, она же уже СУБД и ничего больше.

Относительно платформы - раньше так и было.
А теперь и сама HANA - и БД и платформа. Используйте как удобнее.

Комментарий от  

Олег Точенюк

  |  08 декабря 2013, 02:21

Относительно платформы - раньше так и было.
А теперь и сама HANA - и БД и платформа. Используйте как удобнее.

О, замечательно может вы тогда объясните популярно, что такое SAP NetWeaver - т.е. почему SAP ECC это просто ну скажем ERP система, а вот SAP NetWeaver это уже платформа, а теперь уже HANA, она же база данных, она же система управления этой базой данных, она же уже тоже стала оказывается платформой. А то у меня сдается что никто внятно, кроме маркетинга, который часто сам не знает что говорит, объяснить что день насущный нам несет, не может...

Комментарий от  

Павел Сидоров

  |  14 декабря 2013, 21:43

О, замечательно может вы тогда объясните популярно, что такое SAP NetWeaver - т.е. почему SAP ECC это просто ну скажем ERP система, а вот SAP NetWeaver это уже платформа, а теперь уже HANA, она же база данных, она же система управления этой базой данных, она же уже тоже стала оказывается платформой. А то у меня сдается что никто внятно, кроме маркетинга, который часто сам не знает что говорит, объяснить что день насущный нам несет, не может...

Олег, я это понимаю так: платформа — это то, что абстрагирует железо и ОС для использования в приложении и предоставляет определенные «высокоуровневые» сервисы (например, сервис идентификации пользователей, сервис абстрагирования от БД и т. д.). Обязательным компонентом платформы является среда исполнения кода приложения, при этом перечень доступных языков программирования фиксирован (так как только для них платформа предоставляет свои сервисы в виде API). Если применить это определение к старушке R/3, то платформой можно было бы назвать железо + ядро SAP + модуль SAP Basis, а прикладные модули - это приложения на этой платформе. Но такие понятия были тогда не в ходу. Хотя аналогия понятий Basis и Platform очевидны. Позже SAP Basis стал частью Netweaver, который стал включать помимо среды исполнения для ABAP среду исполнения для Java, а так же другие сервисы. Поэтому с этой точки зрения HANA — это платформа, in-memory СУБД в ней — это только ее часть (хотя, конечно же, главная), которая сама по себе называется Index Server (название не применяется маркетологами). Помимо СУБД в ней так же присутствуют среды исполнения Java, Server-Side Java Script и др.

Комментарий от  

Олег Точенюк

  |  16 декабря 2013, 13:04

Олег, я это понимаю так: платформа — это то, что абстрагирует железо и ОС для использования в приложении и предоставляет определенные «высокоуровневые» сервисы (например, сервис идентификации пользователей, сервис абстрагирования от БД и т. д.). Обязательным компонентом платформы является среда исполнения кода приложения, при этом перечень доступных языков программирования фиксирован (так как только для них платформа предоставляет свои сервисы в виде API). Если применить это определение к старушке R/3, то платформой можно было бы назвать железо + ядро SAP + модуль SAP Basis, а прикладные модули - это приложения на этой платформе. Но такие понятия были тогда не в ходу. Хотя аналогия понятий Basis и Platform очевидны. Позже SAP Basis стал частью Netweaver, который стал включать помимо среды исполнения для ABAP среду исполнения для Java, а так же другие сервисы. Поэтому с этой точки зрения HANA — это платформа, in-memory СУБД в ней — это только ее часть (хотя, конечно же, главная), которая сама по себе называется Index Server (название не применяется маркетологами). Помимо СУБД в ней так же присутствуют среды исполнения Java, Server-Side Java Script и др.

Спасибо

Комментарий от  

Анатолий Ермаков

  |  26 февраля 2014, 23:05

Олег, спасибо за Ваш содержательный комментарий.
 
Не очень понятно, что вы подразумеваете под термином документ, но тем не менее.
Если Вы имеете в виду отдельные транзакции, создаваемые пользователями системы, то да, ERP можно с полной уверенностью считать таковой. В данном смысле модель работы SAP ERP системы, существовавшая до появления SAP HANA, в полной мере отвечала такой концепции, поскольку база данных в ней использовалась лишь как хранилище информации.
Напротив, в концепции, в которую включается SAP HANA как база данных, появляется возможность переносить отдельные элементы логики приложений на уровень базы данных и за счет этого повышать производительность транзакций и отчетов..
Если же мы имеем в виду бизнес-логику приложения ERP как таковую, то при миграции на SAP HANA она не изменится. Существует также возможность включать/выключать выполнение оптимизированной на SAP HANA логики стандартных прорамм/транзакций. Стоит также отметить, что в версию ERP для SAP HANA включены дополнительные преднастроенные приложения на базе технологии HTML5 (например, MRP Cockpit). Для процессов, построенных на пользовательских разработках, оптимизацию необходимо будет делать дополнительно.
Таким образом, в случае применения SAP HANA в качестве СУБД для SAP ERP, заказчик получает не только базу данных, позволяющую обрабатывать большие объемы данных с более высокой скоростью, нежели традиционные СУБД, но и платформу для построения новых приложений на основе процессов в ERP, позволяющих анализировать информацию в режиме реального времени. Это позволяет нам говорить о  возвращении к реальному значению термина «Real-time data processing». Причем речь идет не только об ускорении выполнения традиционных отчетов, но и о функциональности, которая считалась нереализуемой ранее из-за проблем с производительностью. Примером может являться сегментация клиентов в CRM приложениях для торговых организаций. Данный процесс в традиционной архитектуре требовал накопления информации и ее переноса в BW, а теперь может выполняться непосредственно в системе CRM.
Говоря про аналитические возможности, я хотел бы отметить, что как минимум в ближайшем обозримом будущем хранилища данных будут по-прежнему строиться на основе SAP BW, теперь использующем SAP HANA в качестве СУБД и платформы для построения real-time отчетности. Связано это в основном с тем, что в настоящее время решение SAP BW предоставляет огромный объем функциональности, позволяющей, к примеру, вести предварительную обработку данных, строить системы бюджетирования и консолидации, реализовывать концепцию data aging с помощью решения NLS. Вероятно, настанет момент, когда данная функциональность будет интегрирована в единую платформу для транзакционных и аналитических систем.
 
Сергей Осин

"появляется возможность переносить отдельные элементы логики приложений на уровень базы данных"
 
Я правильно понимаю, что это отход от классической 3-х звенной модели клиент-сервер?
При этом
"По первым прикидкам для оптимальной работы СУБД HANA может потребоваться до трех раз больше процессорных мощностей по сравнению с традиционными базами данных."
 
In-memory технологии - это хорошо, но

Комментарий от  

Олег Точенюк

  |  27 февраля 2014, 12:27

"появляется возможность переносить отдельные элементы логики приложений на уровень базы данных"
 
Я правильно понимаю, что это отход от классической 3-х звенной модели клиент-сервер?
При этом
"По первым прикидкам для оптимальной работы СУБД HANA может потребоваться до трех раз больше процессорных мощностей по сравнению с традиционными базами данных."
 
In-memory технологии - это хорошо, но

Ну скажем так для ERP такой перенос довольно проблематичен будет. Для разных BO/BW и иже с ними наверное не проблема.