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

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

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

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

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

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

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

Ну например так:
MAX_PBT_WPS = 24
FREE_PBT_WPS = 22 (на момент запуска)
 
Пользователей скажем так где-то 1100-1200, понятно что активных гораздо меньше. Система S/4

Да, диалогов. А у вас какие значения вернет SPBT_INITIALIZE в продуктиве?
Насчет пользователей не располагаю достоверной информацией.

Диалогов? 100 процессов не попадалось если честно, обычно гораздо скромнее. Кстати это какое количество пользователей у вас в системе, если не секрет, что более 100 диалогов открыто?

Ограничение группы серверов не более 25% от общего количества процессов. Всего более 100 процессов. Это разве много?

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

Если 5-8 часов разделить на 30-40 свободных процессов, получится 7-16 минут.

Чего-то у меня цифры не бьются. Например на установку статуса пусть уходит 1 секунда, и время закрытия 5 часов итого за это время при последовательном закрытии у тебя закрывается 5 * 3600 = 18 000 заказов. После распараллеливания, заказ как зарывался за 1 секунду так и будет закрываться, что его параллельно, что последовательно грузить (бапишке фиолетово она в своем процессе отработает необходимое ей время как ты ее не крути). По твоим словам, теперь это все стало отрабатывать за пару минут, ну пусть это будет 5 минут для ровности. Итого у тебя каждую минуту закрывается сколько? Правильно 3600 / 5 = 720 заказов. Короче я в своей жизни систему с 720 свободными процессами не видел еще, твоя видимо первая будет, ну это чтобы оно таки за пару, точнее 5 минут отработало. В общем если бы была реальная статистика с рабочей системы приведена, было бы чуть интереснее. В свое время когда такое делал я просто привел цифры, чтение 120 000 документов:
 
Паралельно 3 процесса: 11 520 002 милисекунд
Последовательно : 20 632 688 милисекунд
 
А ну и сейчас перформы уже не модно Василий К. придет будет говорить, что это не правильное программирование :-), на классах параллельность выглядит чуток интереснее и красивее в реализации, программа обработки выглядит типа так:
LOOP AT <по каким-то объектам которые надо обработать>.
lcl->read( ).    "Прочитали что надо обработать в процесе
lcl->process( ). "Запустили процесс обработки
lcl->wait( ).    "Ждем если нет свободных процессов, иначе идем на следующий шаг.
ENDLOOP.

а можно вопрос немного переиначу:
что делать, если такой человек уже принят? и он уже формирует архитектуру и выдает ТЗ и уверен, что он прав, и уверяет других, что так лучше?
и там уже не 2 + 2 = 5, там 2 + 2 = 'ЛучшийВмиреОтвет подбери себе сам и с музыкой'.

Ну что же раз желающих дать правильный ответ нет, или они очень заняты, напишу почему нет. В системе S/4 как и в предыдущих системах SAP ECC, завод всегда однозначно связан с балансовой единицей, через связку таблиц T001W - T001K - T001 следовательно, если кто-то делает таблицу, где ключами выступают поля БЕ + Завод, этим самым человек показывает свое абсолютное непонимание схемы БД в части логистики, а с другой стороны, ну раз он использует в примере, такую связку, то видимо он представляется всем как специалист по абап в области логистики, коим по моему мнению он не является ни в каком виде. Вот поэтому я не взял бы на работу такого абапера, который не понимает базовых основ в системе в той функциональности на которую он по видимому претендует. Ну это тоже самое, что математик пишет 2 + 2 = 5, на вопрос продемонстрировать операцию сложения. Как говорится а что тут такого, мы же про знак плюс, а не правильность написанного действия.