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

«Авто­ма­ти­че­ское ко­пи­ро­ва­ние полей в до­ку­ме­нтах SAP FI»
Олег Башкатов:
Это я к фразе в колонке:   " То есть поле Ссылка всегда содержит номер, известный дебитору. Это поле затем может использоваться при поиске документа в момент разноски банковской выписки....
«Пошаговые ре­ко­ме­нда­ции по созданию отчётов с испо­льзо­ва­ни­ем SAP Query»
Вячеслав Контарев:
Для присвоения транзакции к запросу необходимо знать имя программы. Его можно получить в транзакции SQ01, меню Запрос-Другие функции-просмотреть имя отчета. Далее, создаем транзакцию в SE93 и...

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Рестарт SAP ERP и влияние на SAP BW

11 сентября 2013, 16:48

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

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

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

Чтобы завершить ввод данных ОПЭ и выполнить тестирование закрытия периода и одновременно начать подготовку продуктивных данных следующего периода, в ERP могут поступить достаточно просто: сделать копию текущего манданта в той же системе. В откопированном манданте пользователи продолжают добивать данные, разработчики отлаживают механизмы закрытия периода, основной мандант очищается и в нем выполняется ввод данных только нового периода.

 

Казалось бы, очень простая операция для ERP – копирование манданта, но она сопровождается далеко идущими последствиями для SAP BW. Причина кроется в организации таблиц системы: таблицы ERP манданто-зависимы и при копировании манданта происходит копирование и данных в таблицах; копирование манданта BW не имеет смысла т.к. таблицы с данными в BW манданто-независимые. Для SAP BW размножение и деление ERP на манданты является фактором который  требует перестройки информационного хранилища и ETL.

Классический пример из курсов SAP BW рекомендует примерно следующий подход: «Когда у вас есть данные из одной системы «A» и такие же данные из другой системы «B», модифицируйте ключ в BW добавив в него, например, префикс системы»… Хороший совет, но всякая ложка хороша к обеду.

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

Возможным вариантом решения в части SAP BW может являться подход с перенастройкой соединения системы тестирования BW (Q) на скопированный мандант ERP для последующей отправки данных в BW (P) систему. Удобно, доступно, но не всегда выполнимо по той причине что система тестирования BW (Q) как правило пребывает в состоянии отличном от BW (P), что определяется ее функциональным назначением, т.е. часть функционала вообще может быть неработоспособной.

Второй вариант – гомогенное копирование BW системы, т.е. копирование с данными всей системы. Способ очень затратный по ресурсам и трудоемкий по времени. Необходимо заранее спланировать и обеспечить наличие дискового пространства для формирования копии, достаточный объем системных ресурсов для разворачивания системы, наличие ресурсов базы данных для обеспечения работы системы.

Какой бы путь не был выбран: добавление ли новой исходной системы к текущим соединениям BW; использование ли BW (Q) системы как промежуточного звена в поставке данных для анализа, или полное копирование BW (P) в BW (P’), во всех случаях придется столкнуться с риском противоречия данных:

- противоречия в текущих значениях номеров документов. Документы, проведенные в двух системах после копирования, с одними и теми же номерами будут иметь разный смысл.

- долгосрочные документы, как например, контракты (SD, RCM) могут оказаться продублированными в двух мандантах.

- в BW могут быть инфообъекты, в которых отражаются транзакционные и быстроизменяющиеся основные данные. Например, заказы ТОРО, заказы СО, тех.места ТОРО. При наложении этих справочников из 2-х систем ERP возникнет противоречие.

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

Не позволяйте ERP размножать продуктивные манданты, тогда BW будет легче а пользователю приятней…

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

Олег Точенюк (Рейтинг: 10202) 19:32, 11 сентября 2013

Илья, а Вы такое в жизни видели? Просто описанная вами схема с копированием первого квартала в новую систему и параллельный ввод данных уже в системы первого и второго кварталов показывают, что для вас в этой схеме ERP это просто хранилище первичных документов, что далеко не так, потому что после копирования все что вы вводите в первый квартал системы 1, по факту практически никак не сможет быть довведено во второй квартал системы 2, да вы выйдете максимум на входящие остатки второго квартала системы 1 со старой системой, но для системы второго квартала, вы никогда уже не получите правильных переходящих остатков, а в таком случае зачем ввод каких-то документов в эту систему второго квартала? Полное ощущение, чтобы люди без дела не шатались, пока группа внедрения исправляет ситуацию первого квартала в системе 1 и не парили мозги своими вопросами?
 
PS: Кстати,если уж такие страсти, то это наверное как-то сразу можно прогнозировать и при разработке BW просто во все ключи добавить мандант, дело на 1 минуту, зато потом я так понимаю, пусть группа внедрения ERP хоть каждый квартал делает новую систему, ну если ей больше заняться нечем.
10:26, 12 сентября 2013

Илья Муковоз (Рейтинг: 4972)

Приветствую.
Внимательно читаем 4-й абзац.
"Дело на 1 минуту" - классическое заблуждение консультантов ERP, спасибо! Материал в точку.
11:43, 12 сентября 2013

Олег Точенюк (Рейтинг: 10202)

Да я прочитал, я вообще интересуюсь, вы где-то такое видели с копированием продуктивных мандантов (классическое заблуждение, не знаю кого) и ... если видели, то добавить мандант нужно было на этапе проектирования, если не видели, тогда согласен, в самом конце перед стартом проекта, что-то менять глобально уже проблема.
15:02, 12 сентября 2013

Илья Муковоз (Рейтинг: 4972)

Видел, и не только видел, но и хранилище перенастраивал под изменившиеся условия.
Учесть на этапе проектирования можно только очевидные вещи. Влияние человеческого фактора проектированию не подлежит т.к. если закладывать все возможные ситуации, никаких ресурсов не хватит.
22:19, 12 сентября 2013

Олег Точенюк (Рейтинг: 10202)

Ну если тут есть реализаторы такого копирования ERP, то хотелось бы у них узнать каким образом они после такого копирования в новом продуктиве получали правильные входящие остатки, как по логистике так и по финансам?!? Потому что такая реализация подразумевает что ERP это первичный регистратор документов, больше ничего... баланс, остатки по складам и закупка все в BW, что ли?
12:45, 30 сентября 2013

Илья Муковоз (Рейтинг: 4972)

Олег, давайте будем честны.
ERP и есть первичный регистратор документов. Баланс, ОПУ, остатки должны формироваться в том числе и в BW. Почему, думаю объяснять не требуется, но для примера возьмем хотя бы один аспект - производительность и анализ детализации, цена вопроса простоя  ERP из-за тяжелых ABAP отчетов несоизмерима с штатной работой BW, где все механизмы оптимизированы для формирование отчета и выполнения OLAP анализа.
К вопросу о том как получить правильные остатки ;) могу прочитать целую лекцию о том как и когда, в какой последовательности что нужно внедрять чтобы "остатки" были правильными ;)
11:53, 01 октября 2013

Олег Точенюк (Рейтинг: 10202)

Ну одна компания, в одной другой компании, уже как-то пыталась оборотную ведомость движения материалов на BW сделать, ну они при мне ее месяцев 10 делали, потом я оттуда ушел и они еще ее делали.. не знаю какой там результат к сожалению. Но все время что-то мешало.
 
Кстати, а зачем баланс формировать в том числе и в BW? Если он уже есть в ERP и кстати строится он не так чтобы долго. А смысл?