Всем добрый день. Возможно что-то подобное уже обсуждалось, но я не смог найти (..

Задача в следующем: есть система в компании, на которой разработчики и специалисты по внедрению настраивают какие-либо бизнес процессы по HR, FI или еще по каким-либо компонентам..

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

Здесь два пути: либо настраивать данное решение в ручную, либо (в моем понимании это должно работать.. ) осуществить перенос настроек из нашей системы в систему заказчика и частично данные настройки доработать.

Так вопрос в том: что должны делать первоначально разработчики и "внедренцы", чтобы администратору потом без лишних шаманских действий можно было вынести данные настройки в запрос и перетащить запрос (или ряд запросов) в систему заказчика?

Насколько я понимаю - должен быть создан проект в транзакции SPRO_ADMIN и в каждом таком проекте должны вестись настройки ОДНОГО бизнес процесса.

Прав ли я и если не совсем, то каким образом производить данную процедуру?

Могу посоветовать посмотреть Best Practices. Как документацию, так и то, как оно устроено. Поймете, в какую сторону двигаться, чтобы было "По правилам"
А вообще я в чудеса слабо верю...

В смысле в чудеса? Имеете ввиду, что заказчик все равно захочет все переделать под себя настолько, что даже смысла не будет перетаскивать решение или то, что подобный перенос нормально не работает? )

Я имею в виду, что для нормальной подготовки решения придется выполнить у себя полную настройку. С нуля, заметьте.
Потом показать это заказчику.
Если он ПОЛНОСТЬЮ удовлетворен, можно перетащить к нему. Любым методом. Хоть через импорт транспортов, которые создавались во время настройки.
Потом все оттестировать у него, в системе разработки.
Потом начать доделки и мелкие изменения в его транспортном ландшафте.

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

Если пойдете по пути Бест Практис, которые есть у SAP'а, там немного другой метод, и рассчитано все на МИНИМАЛЬНЫЕ отклонения от типового решения.
Т.е. надо будет построить систему до максимума, после которого у разных клиентов начинаются отклонения. Попробуйте догадаться, как много Вы сумеете сделать такого, что будет ОБЩИМ для разных клиентов.
В нашей стране это бесполезная работа.

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

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

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

Под Best Practies как я понимаю вы имеете ввиду готовые решения, которые предлагаются за фиксированную плату", как написано на портале help.sap.com (http://help.sap.com/bp_bl604/BL_RU/html/index_RU_RU.htm)?

Похоже на то, но это существует не только для All in one, полезней это для отраслевых решений и т.п.