Подскажите, плз, каким образом должна быть на фирме организована процедура АБАП - разработок?

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

Буду очень благодарен даже за краткие, но неформальные ответы. Спасибо!

читать про методологию ASAP

хотя вообще все это лирика

Я сталкивался с разными подходами, каждый из которых имеет свои плюсы и минусы. Чаще всего разработчикам ставит задачу консультант, описывая на пальцах, что нужно. Кроме этого консультант показывает, как проверить результат и делает тестовые данные. Иногда консультантов заставляют писать подробные спеки, но тогда консультанты ворчат, что легче написать программу самим. Еще на внутренних проектах разработчиков пускают напрямую к пользователям. В таких случаях можно получить замечательный результат, если пользователи толковые.

Если фирма самостоятельно пробует поставить и внедрить у себя SAP абсолютно "с нуля", то такого не бывает или мир перевернулся.

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

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

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

Так что, господа, пишите спецификации.

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

скриншоты это рулез
вот постановки на клочке бумаги для записей - 5*5 см - это да..

а ваще тема - боян многолетний

А вот в этом месте по идее должен возникнуть руководитель отдела разработки и завернуть такую "спецификацию".

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

Сорри за оффтоп, но что-то не слишком лестное для абаперов слышится в Вашем посте. Выбраться в консультанты... откуда?

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

или перейти в другую


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

P.S. Программистов полно, а действительно Хороших надо искать.

Работодатели, как правило, их не разделяют.

для них тем лучше, чем проще и дешевле, поэтому разделение возникает, например, при возникновении проблем или резкой нехватке сроков / бюджета...

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

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