Было бы не плохо продемонстрировать скриншотом как это выглядит в lsmw. Особенно интересно в разделе где прописывается мэппинг.
Пока, если честно, не понятно как это реализовать в lsmw.

Мир далеко не идеален, есть и такие консультанты. :)

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

Олег, доброго дня.
Абсолютно согласен, абапер может уложить систему так что базиснику не снилось. Но и консультанты имеют возможности попортить жизнь.
Ни кому не сказав, включает буферизацию на Z-таблицу размером 30ГБ с документами, со словами "а мне **** сказал, что так быстрее". Результат я думаю понятен. Или другой, включил заполнение инфраструктуры на выходные, логи за пару часов забили директорию в которой был 3-х кратный запас, система встала. Для справки, она в результате была 780ГБ. Ещё вариант: включили параллельную обработку, уже не вспомню деталей, всё бы ничего, вот только одновременно этот процесс запускали 30 человек, и рабочих процессов под такую нагрузку не было предусмотренно. Объяснение такое же простое: "на DEV и QAS у меня всё работало".
Список можно продолжать. У каждого свои истории.

====
как производимые ими настройки и разработки могут повлиять на работоспособность системы в целом
====
Да никак, на то она и настройка, это вы ведь не про абаперов писали? Абаперы те да, положить систему могут быстро и качественно :-)

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

все ж было б неплохо указать в статье, что не стоит параллелить пока не выжали все из последовательной обработки. А то находятся последователи индуских талмудов, так напараллелят, что другие процессы стоят.
 
Пример в статье идеальный, 20 задач, 9 параллельных процессов, задача грузит только CPU, поэтому отлично подходит для параллезации. Получили шикарный прирост производительности 80/12 ~= 6,7 раз. Реальный пример, от Олега дает всего лишь 20 632 688/11 520 002 ~1,79 увеличение, при 3-х кратной парализации.
Лучше вначале разобраться, где у вас узкое место и почему оно именно настолько узкое. Иначе есть риск наткнуться на "бо-бо" в продуктивной системе, после "новаторской" оптимизации.

"Обучение ABAP. Отладчик. Основы" на сайте 29.09
в календарь пришло приглашение на 30.09
где то неточность!

Настройки проводок это то, за что Мари Лоран, получает деньги, поэтому спасибо ей, что она поделилась, скажем так безвозмездно, т.е. даром, о том что есть такая вот функциональность. Теперь у вас есть два варианта, разобраться самой или пригласить независимого консультанта Мари Лоран, которая сделает это за вас, конечно уже не безвозмездно, т.е. не даром :-)

Статья замечательная. Но хотелось бы подробнее узнать по настройке проводок.