Многое зависит:
а. От специфики предприятия (отрасли), на котором внедряется SAP
б. От отношения консалтинговой компании к тому, насколько надо удовлетворять потребности бизнеса клиента.

Любые абап разработки = доп. затраты консалтинговой компании, поэтому в 99% случаев консультанты будут говорить о великом и могучем стандарте и бест практис, которые на религиозном уровне мешают делать абап-разработки, а на проекты, на которых выполнены разработки презрительно говорить, "фу, назетили, совсем систему испортили"

С другой стороны, есть отрасли, в которых по-другому просто нельзя, например, любимый мной Ритейл.
Тут даже для элементарного перемещения запасами между складами нужно делать свою удобную оболочку, так как:
1. стандартная транзакция migo не дает возможности массовой загрузки перемещаемых позиций, максимум - копирование из буфера обмена по 20 строк (сколько помещается на экране)
2. Большое количество пользователей. Обучить несколько тысяч пользователей двигать товар в migo и не жать лишних кнопок - реально весьма затратная для Компании задача и повторять ее придется с завидной регулярностью из за высокой ротации персонала.

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

При этом будет создаваться стандартный документ SAP (документ материала) через сертифицированный интерфес создания таких документов (bapi), то есть нет никакой угрозы последующим обновлениям системы.

В общем, абап абапу рознь, но если исполнитель категорически отказывается от разработок - это говорит только о том, что он режет свои косты и не интересуется бизнес-потребностями клиента.

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

Если в компании один человек делает один заказ на закупку в неделю, можно его послать в стандартную транзакцию ME21N.
Если такие же заказы делает 20 человек, каждый по 10 заказов в 100 позиций в день, то без абап не обойтись (загрузка заказов из Excel).

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

А для абаперов важны сроки разработок, наличие/отсутствие стандартных средств/инструментов для реализации функциональности, степень сложности дальнейшего сопровождения. Поэтому чисто теоретически задача то решается, но уровень затрат (времени, усилий) может оказаться таким, что лучше ее и не решать.

2 LKU - От заказчика, всё же больше зависит, чем от внедренца. Грамотный заказчик, заинтересованный в работающей системе, всегда будет считать, что дешевле и перспективнее - обучать персонал стандарту (могут делать и стажёры за 3 копейки или ключевики на месте), или держать штат консультантов + абаперов, или же платить аутсорсеру за постоянные допиливания и исправления багов в разработках. Если Z-решение реально позволяет уменьшить трудозатраты на ввод/обработку информации в долгосрочной перспективе, сократить число критичных ошибок пользователя, то, конечно, это хороший Z. А если "бантики и рюшечки" под капризного пользователя?..Тут как с автомобилем - по совокупной стоимости владения решения надо оценивать, а не только по сиюминутной выгоде. Для разработчика, конечно, вдвойне выгоднее напилить недокументированного Z, который только он потом сможет поддерживать, и сидеть припеваючи, при условии, что проблем с оплатой его работ нет. Имхо, ресурсы на ABAP-разработки лучше потратить не написание оболочек для стандарта, а на расширение функционала, которого в стандарте нет, либо он не до конца отвечает требованиям законодательства/бизнеса. P.S Это, конечно, про тех заказчиков, которым важен результат, а не процесс)))

Все по-своему правы, кроме топик-стартера
Давайте не будем разводить холивар, но по характеру вопроса очевидно, что проект только начался, а пользователи "всю систему в целом (с)" еще не поняли, и обращают внимание в первую очередь на то, что лежит на поверхности. Из своего опыта вспоминаются требования переименовать заводы в филиалы, хрестоматийные 40 символов в наименовании и 4 знака после запятой, мега-отчеты >200 полей, и чудо-транзакции которые делают все сами. SteFFun я бы посоветовал на данном этапе интерфейсами не заморачиваться (я тоже первый раз когда увидел, был к шоке), и тратить ресурс внедренцев по разработкам (а он не резиновый) на отчетность. Здесь можно требовать всё что угодно. По теме могу добавить, что скрасить экраны можно используя варианты (поскрывать ненужные поля и закладки).

Коллеги, развивать холливар у меня мыслей не было, просто накипело от продвигаемой политики, что Z-решение это всегда плохо.

На практике, конечно, надо трезво оценивать все плюсы и минусы разработки в каждом конкретном случае.

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

to gveg1980. Заказчик становится грамотным не сам по себе. Для этого нужно, чтобы у представителей заказчика уже был обширный опыт работы по внедрению SAP на аналогичных проектах, а это далеко не всегда так.

Поэтому существенная часть ответственности на консалтинговой компании, которую как раз и нанимают на проект ради ее экспертизы грамотного внедрения проектов.

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

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

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

Я согласен с LKU. Если операция массового используется достаточно большим количеством пользователей, и запускает достаточно несложный процесс (поступление или перемещение материалов, например), то можно поставить вопрос о z-разработке с удобным для пользователя интерфейсом, в привычных для него понятиях и с ограниченным функционалом (ничего лишнего, только то что надо), а все действия выполнять в фоновом режиме через различные способы (BAPI, batch input, ....). Но если процесс достаточно сложный, включает несколько шагов, каждый из которых зависит от предыдущего, при этом на каждом шаге могут создаваться/изменяться объекты системы, то тут стоит хорошо подумать о целесообразности такой z-разработки.

Да, и эта штука будет называться интерфейсной программой. Полностью Z, но с использованием пакетников и BAPI. А вот грубо ломать стандарт или пытаться объединить стандартные экраны в свою разработку - не всегда полезно.