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

Про ОПЭ, LadyWind не повторяй глупостей про мгновенные старты за сейлзами вендора. В любой российской компании нужна выверка данных в стартующей системе и в старой и объяснения расхождений на отчетном периоде(ах) месяц, квартал. Верить на слово что мы тут тебе внедрили все по высшему разряду это я считаю может только очень доверчивый Заказчик или тот у которого до этого учет был не до копейки и ему в бухгалтерском балансе пару десятков тысяч(миллионов) туда/сюда не важно.
Слышал по этому поводу и песни сейлзов SAP CIS и рассказы консультантов реально работающих там на проектах - что-то почему то показания расходятся.

Я по мойму не абстракции писал - есть конкретно проектные работы, на ОПЭ это прогон всех операций Заказчика за месяц, квартал - причем тут плохое планирование РП, когда именно на этом этапе задействуется разработчик для устранения неучтенных в разработке ситуаций? Если Вы отрицаете необходимость активного участия разработчика на ОПЭ я и спрашивал предлагаете весь объем тестирования операций перенести с ОПЭ на этап настройки и разработки?
Давайте оперировать объемом работ которые должны выполняться на каждом этапе, а не то что все РП - м...ки и от них все зло, а консультантам нечего с разработчиками делить. Уже хорошо что Вы в отличие от LadyWind Опытную Эксплуатацию из этапов внедрения не выкинули, правда этапа тестирование я что то ни в ASAP-е, ни в ГОСТЕ не припомню. Интеграционное тестирование или предварительные испытания это работы этапа Настройки и разработки что по ASAP-у что по ГОСТ-у.

поправлю - по ASAP это часть final preparation, а не realization (настройка).

Что касается заработка консалт-поддержка: риски не получить деньги, испортить нервы и тп я бы оценил так
зарплата консалта >= (1.5 или 2.0) * зарплата поддержки. Если предлагают меньше, то смысла связываться нет.

Что касается "качества":

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

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

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

Приведу аналогию: можно покупать квартиру самому , Не привлекая своего юриста( грамотного риэлтора) , но тогда вопрос о том, Кто защищает Ваши интересы ( интересы компании в сделке ), остается открытым, а результат плохо предсказуемым.

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

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

А про бонусы с тараканами - это для любителей. Я выразил свое мнение по данному вопросу, если у вас другое - нет проблем. Соглашайтесь.

Обычно не абаперам, а консам надо бегать и переделывать ТЗ, и получать люлей за плохо протестированную разработку.
У абапера хата всегда с краю - "что велели - то и накодил, плохо протестили - ваши проблемы", ибо детальный тест функционала в обязанности абапера не входит. В дамп не падает прога - и ладушки, можно тестировать (консу).

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

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

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

Недопонял. Концептуальное проектирование стало "опциональным пожеланием"?

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

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

У меня на трети проектов тоже всегда был code review. Спецификации, тестирование это, конечно, хорошо, но пока программа не прошла code review старших товарищей в центре, ни в какой кволити ее не перенесут. И это правильно – аудит программ тоже нужен. Я, как консультант, не смогу сказать, насколько оптимально написана прогрмма, если на тестовых данных все ОК, и в целом меня все устраивает.
Далее, пока БИЗНЕС не подпишет стандартный документ, что в кволити системе их все устраивает (бизнес делает тестирование всех основных процессов), ни в какой продуктив никто не перенесет. Именно бизнес тестирует и подтверждает, что все ОК. Если разработка затрагивает другие БЕ и т.д., то это уже совем другая песня с регрессионным тестированием.
Схема работает очень хорошо, бизнес задействован на проекте на 100% рабочего времени. Да, нужно много времени и денег, но система в целом стабильна после продуктива.
На других проектах, где не было стольких точек контроля, все было намного печальнее. Да, дешевле и быстрее, но порой и во время продуктива нужны были срочно еще пару программистов.
При первой схеме это просто нереально. 95% ошибок обычно отлавливается до продуктива в том числе бизнесом, оставшиеся 5% испраляются в рабочнем порядке. Какие-то нюансы можно не учесть, но общая логика, база не меняется.
При остальных схемах всякое бывало включая работу по ночам, чтобы более менее вовремя закряться. Это был мрак. Есть с чем сравнивать.
Очень жаль, что часто экономят и классические этапы внедрения пропускают, сжимают, экономят. Результаты потом соответствующий. Если бизнесу нормально отвели времени, есть возможность протетсировать 90-95% бизнес-процессов, все исправить, то никакая ОПЭ не нужна. Да, это больше денег, да это скорее всего этапность внедерения на супер больших проектах. Исходя из моего опыта.

По теме. Вообще, как повезет в целом. И там, и там можно как получить неплохой опыт, так и очень узко специализироваться на чем-то. Нужно сравнивать конкретные предложения в детялах, так сказать.
У меня есть коллега, с которым я начинала в консалтинге примерно в одно время. За год результаты были очень разные. Мне повезло больше, у меня были задачи разнообразные. Его отправили на очень крупный проект, занимался только одной частью одного участка.
Но я бы все таки пошла в консалтинг.
А вообще, если есть желание, то можно и там, и там пробиться, чему-то самому научиться и т.д.. А для резюме потом обычно консалтинг весомее (могу ошибаться, конечно).

Изначально речь шла вот о чём

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

А давайте не путать опытную эксплуатацию и опытно-промышленную?
ImpCons, тебя касается в первую очередь.

З.Ы. По поводу консультанта и заказчика: и непгеменно гасстгелять!