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

Схема, о которой упоминает Андрей, для российских компаний "гибче". Плюс иногда контрагенты в данном случае представляют интересы тех же самых собственников, либо это компании-партнеры. А риски неполучения конечного продукта решаются переговорами (иногда в "товарищеском суде" :) ).

А почему ты так считаешь? был какой-то случай из практики?
указанная тобой схема больше напоминает схему "вывода денег из оборота".
 
В случае сделки купли-продажи увеличиваются риски неполучения конечного продукта (заказчик может отказаться покупать, а подрядчик продавать), а также увеличиваются транзакционные издержки (при продаже нужно налоги платить).
Кроме того, возможны случаи, когда подрядчику передают компоненты, общая стоимость которых настолько велика, что подрядчик не может себе позволить их купить.
 
Т.о., и та, и другая схема имеет право на существование и, в общем случае, нельзя сказать, что 1ое лучше 2го или наоборот. В России, Германии ли, или еще где-нибудь (хотя у меня не такой большой опыт, чтобы говорить за все государства :-) ).
 
И еще: подрядчику могут передавать не только сырье, но и технологичные компоненты.

Считаю что для России больше подходит схема когда компания продает сырье по одной цене, а затем покупает у этого же контрагента готовую продукцию по другой. В схеме с давальческим материалом всё равно должны быть основания для перевозки и передачи сырья.

Пользователи не хотят участвовать в проектировании системы, не хотят знать учет и формировать TЗ.
Пользователи хотят запустить файл setup.exe и иметь интуитивно понятный интерфейс как у apple.

А тем временем книжка вышла и в бумажном формате...
 
sapexpert.co.uk/the-essential-sap-career-guide-is-now-available-in-paperback

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

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

Алексей, здравствуйте.
А где в этой архитектуре место для архивированных данных?
Для всех уровней срок жизни не превышает нескольких лет.
Если существуют требования  по архивированию данных на сроки измеряемые десятками лет с целью обеспечения к ним редкого доступа по запросу. То в таком контексте, архивирование вообще не является задачей для BW, а должно достигаться на уровне исходых систем?
Тогда данные планирования после переноса в такой архив, также надо рассматривать в качестве исходной системы? И в случае развития текущей модели данных, доступ к архивным может быть настроен за счет настройки ETL и переноса по запросу?

Олег, и в последний момент перед стартом системы какой-нибудь умник решит поменять что-то кардинальное. Придется ведь не только все настройки перепроверять, но и документацию переписывать.
 
У меня были такие примеры.

Чем то напоминает google :)

еще можно использовать средство поиска в SE93 по тексту (если мы говорим о транзакции).
Особенно при Z-транзакциях настройки помогает.

Могу показать проект, где этой документации уже вагон, причем некая компиляция ГОСТ 34.* + ASAP в одном конверте. И все это как раз в процессе внедрения :-)

Андрей,
Отчасти Вы правы, что поиск в Google может помочь больше, чем поиск в SAP.
Тем не менее, я знаю людей, которые пользуются описанными способами даже после 10(?) лет в SAP.
А насчет "документация к проекту внедрения, где описаны все настройки" - это Вы оптимист. 8-) Да и сама документация есть только на уже "живых" проектах. В процессе внедрения самой документации, как правило, еще нет.