В SAPе очень много настроечных функций, не связанных с программированием и не являющихся "пользовательскими". Идеальный проект - проект, на котором разработчики не нужны вовсе, так как почти все разумные требования Заказчика по настоящему квалифицированный консультант может решить только с помощью настроек, не прибегая к программированию. Называть консультанта "в первую очередь очень квалифицированным пользователем программы" imho по меньшей мере забавно.

Ни одного идеального проекта не видел

Я в том смысле, что кансультант, который не может работать с программой в качестве квалифицированного пользователя, не сможет не только проконсультировать юзеров, но даже проверить правильность своих настроек. Поэтому, ИМХО, в первую очередь консультант должен стать уверенным пользователем - это тупо отправная точка. Это как для абапера умение пользоваться средой разработки.

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



А я видел, если не считать три смартформы и программы печати к ним

Для России это фантастика, да и не все в SAP хорошо доделано, тем более в SAP Россия

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

Не говоря уже о той уверенности, которую имеет каждый кто, знает систему изнутри, а приведенные тут примеры, дескать, когда такие консультанты со знанием все портили, говорят лишь о том какие они плохие специалисты и не надо их в пример ставить тут.
Нормальному человеку знание как работает система никогда не помешает сделать свою работу, когда надо он полезет в дебри системы через abap когда надо только в spro согласно IMG добавит галочки и успокоится. Главное, чтобы на плечах был не котелок, которым только едят

Услышал я обидные слова,
Зачем мол вам саперам голова?
Держать удар, отвечу я вам всем,
И головой я, между прочим, ем.

приведу пример. что-то у меня не получалось (с палашом вероятно), пишу базису - а ну быстро sap_all (и вообще почему его нет у вашего начальника системного отдела (или уже выше, не помню)). ответ : скажите что вам нужно, и мы всё сделаем. Млин, думаю, - совсем распустились.
- "быстро - сказал!" (это к - "быстро залез в дебри").
ответ - "нет.
- "как это нет?
- "а вы сами нас так научили."
- вот млин, думаю, и правда...год вбивал им это в головы. стыдно немного стало, но и гордость - устояли, настоящие бойцы
В самом деле - не должен организатор работы лезть в код, кодер - в систему. Разделение труда и специализация важнее кажущейся "простоты". Локально может и есть результат, но в стратегическом плане, отработка взаимодействия гораздо полезнее.
p.s. подавить в себе "я такой супер-пупер, всё умею." не блистать интеллехтом, а воремя поделиться работой (и заработком).

А Вы не считаете, что если потребовать в спецификации, чтобы было точно указано откуда и что брать (не надо указать еще - как брать?), что с этим делать, куда положить и как вывести, то рынку станут не нужны не то что эксперты, а даже просто опытные программисты на абапе? Вед абапер получает в два раза больше, чем программист на жаве или Си не просто так, ценится дорого не умение оттранслировать алгоритм в термины абап, а именно программирование под САП (а уж абап там или жава или какой новый язык появится через пару тройку лет - неважно). А программист, от кодера, как раз и будет отличаться тем, что имеет представление о логике работы Системы, знает, или может отыскать, где какие данные какой из модулей хранит, как с ними работает и как ЕМУ с ними работать ПРАВИЛЬНО (чтобы не нарушить общую логику работы Системы).
А то что Вы описали (чтобы задача немутная, алгоритм, табличик поля) - с этим и кодер из Индии справится по 200 долларов за десяток на удаленке. ИМХО.

Впрочем уже и без меня сказали...

2Road Runner
Я считаю, что есть работа с юзером и системой в режиме настройки и пользования, есть кодинг на абапе, есть понимание архитектуры системы и понимание, к каким изменениям приводят изменения этой архитектуры.
Попытка возложить ответственность за архитектуру на рядовых абаперов, ИМХО, - аферизм.
Попытка возложить это на рядовых консльтантов, которые дальше интерфейса программы не лезут - аферизм того же порядка.

Какие решения могут принять и те и другие по доработке программы? Да чиста косметические, незатрагивающие содержимое базы и то с натяжкой. Или я опять ошибаюсь?

Именно по этому на проекте, как правило работает команда,
а не один абапер или один консультант.


В программировании можно выделить такие понятия как developer и coder.

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

Johnny_nvkz, другими словами девелопер может проанализировать задачи консультантов на предмет интеграции в текущую архитектуру? Я так понимаю, для этого девелопер должен достаточно хорошо и быстро "переводить с языка консультантов" и по сути владеть "беглым консультантским языком" или тут ему в пару нужен некий "ведущий консультант"?

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

SAP_ALL тут зачем?
про разделение согласен, но тут вот заковырка, консультант сап это не чистый бизнес консультант, поэтому ему надо иногда лазить в саму систему, если он это умеет он хороший консультант если нет то у него могут возникать проблемы, которые он конечно может решить другими способами(коллеги, интернет, интуиция...) но иногда проще глянуть что же там внутри творится чтобы понять, что не так делается.
да и глянуть перед тестированием на то, что написал программист, составить грамотное ТЗ(не всегда достаточно знать технические имена таблиц, тк система становится все сложнее и сложнее), оценить пути решения не стандартной проблемы(расширения и прочее).
ведь внедрение сап это не только сделать настройки по IMG как бы тут не говорили все любители простых проектов

Да вот тут с пеной у рта в начале темы отдельные товарищи утверждали обратное.
Хто прав?Я ИДИЁТ, УБЕЙТЕ МИНЯ КТО-НИБУДЬ!!

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

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

Вывод.
Уж если консультант занимается только одним модулем, то можно изучить его от и до.
А АВАРеру нужно достаточно досконально изучить модуль, чтобы самому добыть эту информацию. Если будут АВАРеры, каждый из которых досконально изучил по нескольку модулей, возникает вопрос - зачем нужны консультанты?