Меню

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

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

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

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

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

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

 

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

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

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

Войти

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

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

Олег Точенюк

  |  11 сентября 2013, 19:32

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

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

Илья Муковоз

  |  12 сентября 2013, 10:26

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

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

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

Олег Точенюк

  |  12 сентября 2013, 11:43

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

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

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

Илья Муковоз

  |  12 сентября 2013, 15:02

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

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

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

Олег Точенюк

  |  12 сентября 2013, 22:19

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

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

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

Илья Муковоз

  |  30 сентября 2013, 12:45

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

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

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

Олег Точенюк

  |  01 октября 2013, 11:53

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

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