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

Красиво и полезно.
Было бы не плохо добавить шаг про создание транзакции, было бы полное описание.

Как вариант. Но если мы говорим о простоте, то можно создавать (генерировать)  и через PFCG.

А что SE93 представляет собой нечто супер сложное?!

Красиво и полезно.
Было бы не плохо добавить шаг про создание транзакции, было бы полное описание.

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

Думаю, наладить это реально даже на уникальных проектах, а что уж говорить про внедрения в однотипных компаниях как например Трансгазы, коих десятка полтора по стране. Глобальные компании типа Биг4 имеют темплейты а-ля отраслевые решения и продвигают их на рынок, имея огромное конкурентное преимущество перед остальными. Понятно, что созданию темплейта предшествует анализ и оптимизация решений.
Я видел безуспешные попытки делать это в IBS 5 лет назад. Уверен, что они не одни работали над этим, но отсутствие грамотного стратегического планирования и неготовность заказчиков стандартизировать бизнес-процессы, а также отсутствие специалистов должной квалификации у консалтеров не позволяет организовать эффективный анализ. Без этого, увы, качество решений начинает зависеть от каждого отдельного специалиста на проекте. Уверен, что повышение требований к управлению рисками проекта продвинет этот процесс и облегчит нашу жизнь.

У меня вот сложилось мнение что это или не реально наладить или компании по большей части это не интересно.

>>>руководитель проекта от заказчика не ниже зама генерального директора
 
Ну вообще-то не руководитель а спонсор проекта, а руководитель пусть будет профессионал который знает как руководить :-)

Вопрос а что брать за начало. Какие модули? Так судить можно FI а потом все накручивать.
Да такой вариант тоже вариант. Но именно в накрутке много тонкостей.
Согласен что много зависит от требования заказчика.  Что он хочет от системы? Зачем уходит от прошлой системы на SAP. А может вся идея и заключается в том что SAP интегрированная система. Между модулями должны прослеживается сквозные процессы.
Пример по СО. Можно вести пару МВЗ  и внутренних заказов(СО-ОМ).  И в полу ручном режиме формировать отчетность. При этом себестоимость и выручку собирать вообще без СО. А потом захотеть раз личную аналитической отчетность. И начать внедрять расширенный функционал контроллинга.
И попробуй пользователю объяснить, при работе в продуктив ной системе что появляются другие объекты. Новые процессы.
Это фактически пере внедрение. ИМХО.
 
Согласен хороший проект это не больше года. Но при этом большое количество консультантов разных уровней и руководитель проекта от заказчика не ниже зама генерального директора.!!!!!

Там мысли в слух, если проект хороший то он по определению не может идти долго чтобы там сменились поклонения консультантов и чтобы одни писали КП, а другие его делали... хороший проект, это значит заказчик понимает что и для чего он внедряет, а консультанты знают что они внедряют, а это никак не может идти годами тогда и выходим на срок 9-11 месяцев. Да, потом могут быть расширения функциональности и прочее, но сам проект от начала и до получения результатов, берем часть ERP (FI/MM/SD/CO)  - 11 месяцев, дальше будет болото, в котором конечно могут быть хорошие островки реализаций и т.д. но в целом, это будет болото...

Добрый день.
Еще раз повторюсь.
Имена удачных, по моему мнению, проектов называть не хочу.
Может подняться полемика по поводу их "удачности".
У каждого консультанта свое мнение.
Тем более проекты SAP идут долго. И за это время сменяется не одно поколение консультантов. Каждый вновь приходящий на проект видит только то что уже есть.
И тут два варианта развития. Опять же все зависит от фазы проекта.
Или продолжать что было начато. И не проводить анализ и выдвигать новые предложения и идеи, донастройка  Как правило так делают на фазах "ОПЭ" и промышленная эксплуатация.
Или что то меняют несмотря на фазу проекта.
 
Не зря среди консультантов есть градация (грейды). И очень важно на первых фазах (написание КП) грамотно подбирать консультантов. Но и ту есть моменты. Консультант может быть технически подкован. Много проектов. Но с очки зрения бизнеса мало знаний.
Не зря на западе, консультант SAP это человек в возрасте, не только много проектов по настройки, но так много идей по улучшению бизнеса.
Да, сейчас начали активно выделять "методолгов" на проектах. Но как правило это молодые люди без реального опыта управления.
 
Есть бардак, SAP автоматизирует и бардак.
 
По поводу базы знаний на проектах.
За все время работы консультантом (почти 10 лет) я встречал 1 или 2 проекта где настройки системы соответвовали документации.
 
По поводу SAP. На одном из проектов SAP выступал как рецензент ПР. Скажем так  То что было дано как рекомендации, было полезно на 30 %.
 
Последнее время начал смотреть "бест практив" там много интересного. Но тонкостей мало. На salend больше нахожу )))