OlgaZ, у каждого свой бизнес
А про обучение... чтобы вы изменили? Просто интересно.

Я бы изменила порядок обучения. Как правило внедренцы гонят на время - то есть им выгодно максимально быстро закончить обучение + остальные этапы . Мне как Заказчику - это не критично , сумма у меня не меняется. Рассмотрим обучение - параллельно проходят обучения сразу все модуля. Это неправильно и на следующем проекте я этого точно никогда не допущу.
Смежные модуля должны знать основной функционал друг друга, например ММ и SD , CO и PP - то есть нельзя параллельно проводить обучение . ММ должен учить SD , SD учить ММ, CO учит PP, в РР учит CO ...
А вот когда пойдут нюансы ... это уже концепт и настройки , тогда естественно каждый занимается своим модулем.
Отдельная песня FI - так как по итогам это затрагивает все модуля ... основные курсы должны прослушать все специалисты.
Далее ... BW (я сама помимо того что занимаюсь проектом , так же занимаюсь и BW) и ABAP ... это отдельная песня. То что они должны слушать и тот и другой модуль это само собой. Но и основные модуля тоже ... опять таки ... я не беру настройки концепта и тд... я беру основы.
Сама столкнулась с этими проблемами.
И обучать их надо уже после всех... когда все перейдут на концепт ... тогда начинать обучать BW и ABAP
Я просчитывала , это примерно на 60% увеличит срок обучения, но это того стоит

Скорее не максимизировать, а оптимизировать. Иначе вольете людям в голову кашу, вместо знаний

P.S. и не мучьте Вы абаперов, пусть программируют, не ломайте им голову общими курсами по модулям. Пусть консультанты слушают, грамотно поставленное ТЗ - это работа консультанта.

Частично согласен.
Профильными курсами по MM/SD/FI грузить разработчиков не стоит.
Но постараться найти возможности и прочитать им хоть "обзорку" (SAP01) - очень рекомендую!

Особенно, если помимо IDES использовать реальные примеры архитектуры решений локальной системы.
Или просто, после SAP01 пройти с ними за 1 день подробный инструктаж по архитектурным решениям - чтоб знали, что БЕ не всегда 0001.... и так далее...

Хм... я и моя команда уже внедрили SAP и настроили систему. Это раз . Во вторых это наш опыт .
Лично мне как BW нику очень не хватает (до сих пор хотя сама сейчас разбираю) знаний модулей , тоже самое касается и нашего ABAP ера , так как работаем все вместе.
Maksimus если просто программировать и не забивать голову основными процессами - то на выходе получите ZSAP.
Chirva - нам то уже это не надо ... сами кому хотите обзорку прочитаем .... я говорила о другом ... если бы проект начала сначала или был новый проект.
Именно из за того , что не знали основы работы друг друга ... тратилось очень много время на перенастройки.
Да ... и потом под разгребать и корректировать много приходилось

В части разработчиков подход первоначального ознакомления с основами SAP ERP подойдет не только для новых проектов.
Очень полезно при приходе нового человека в команду.

Наша первая пара разработчиков с первых дней своей работы была погружена в ABAP, а в результате - все Технические задания приходилось пояснять до имени таблицы, до имени поля. Получили разработчиков eq "кодер". Новых уже сначала знакомим с функциональностью, а потом бросаем в ABAP.

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

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

2. Полноценное участие представителей бизнеса (ключевых пользователей) не всегда возможно! Ведь первоначально озвучивается, что такие участники проекта будут тратить на задачи проекта 15-25% своего рабочего времени, а семинары требуют 100% участия.

3. Не по всем направлениям легко выделить обзорные курсы по функциональности, слишком часто нормальный обзор функциональности находится в семинарах второго уровня. Сравните SAP01, AC010 и AC305 - в первом практически совсем нет основных средств, во втором - ОЧЕНЬ поверхностно, а третий - уже сам по себе показывает, как функциональность настраивается.

Chirva... вот вот.... об этом я и говорила ... то же касается BW ... эт я на себе прочувствовала ...
По кол-ву участников на семинарах .... тоже есть что добавить ... наши внедренцы предлагали (что мы собственно и сделали - кстати о чем жалею.. ) чтоб ключевые пользователи слушали с проектной командой... это было зря ... 90% тормозило до ужаса ... как итоги потерянное зря время.
А вот ключевым минимальный обзор и ВСЁ!!!! Этого им хватит! Обучать их уже готовым и настроенным процессам.

И вы считаете что в этом будет виноват только абапер?

P.S. у нас в команде 1 абапер, работает на все модули. Вот и представьте, если я начну читать ему обзорные курсы по всем модулям... он ж с ума сойдет. Возьмите хотя бы ММ с его спецификой, FI, да любой модуль, в принципе. Из обзорного курса он все равно не поймет какие таблицы и как связывать. Я конечно не утверждаю, но в моем случае, мне проще написать ему ТЗ в котором до таблиц и полей расписано что и куда. А от него мне нужен готовый результат в виде реализованного алгоритма.
Если команда программистов, со специализацией на отд. модулях, то да, в чем то соглашусь с Chirva.

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

У нас вопрос наверно в сроках.

Maksimus, не реально обеспечить 100% специализацию разработчику - или быстро оканчиваются задачи, которые ограничены одним модулем,
или приоритетность и срочность задач заставляет закрывать не занятыми разработчиками другие направления.

Обзорный курс не дает 100% знаний, обзорный курс дает представление об основных концепциях, которые заложены в систему.
Зато после нормально прослушанного обзорного курса нужно ОЧЕНЬ мало времени чтоб хоть немного объяснить разработчику основную ТЕХНИЧЕСКУЮ составляющую системы.

Поверьте, намного проще объяснить программисту зачем нужны kna1-knb1 если он уже узнал, что у один дебитор может быть внутри системы указан в разных БЕ.
Точно так же проще показать технический уровень рынков сбыта для этого дебитора, если программист уже своими глазами увидел в обзорном курсе, что это предусмотрено!! Добавив один штрих - показав пальцем kunnr во всех этих таблицах - и уже никогда снова не потребуется тратить время на подробное объяснение "где и как искать данные дебитора". После такого погружения ВЕСЬ рассказ о кредиторе просто сводится к двум фразам: "аналогично, только не сбытовая, а закупочная" + "и таблицы очень похожи, только с маской lf* вместо kn*".

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

Отдельно о негативе (imho) 100% прописанного ТЗ - к огромнейшему сожалению, в большинстве Z-разработок внутри SAP ERP начисто опускают этап проектирования. И расписанное Техническое задание - одна из основных предпосылок этому! Аналитик/консультант считает, что он лучше любого разработчика понимает свою область данных. Описывает в ТЗ все таблицы, поля, связи. Где и что взять, в какой последовательности.
- Что после этого делать разработчику? ТУПО писать код по описанному постановщиком ТЗ.
Какой результат? - 100% наследуются ошибки постановщика. Разработчик не получает нормальной возможности подумать, проанализировать задачу, спроектировать полноценное и оптимальное решение.

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

Какую идею я пытаюсь отстоять - каждому заниматься своим делом:
Аналитику/консультанту - уметь четко объяснить разработчику основные требования к задаче.
Разработчику - уметь найти в системе необходимые данные, не стесняться обращаться к постановщику за требуемыми уточнениями. Главное - уметь применять даже в не больших задачах те знания и принципы, которые ему так старательно преподавали в ВУЗе.

Что не стоит делать:
Аналитику/Консультанту, если он обладает действительно профессиональными знаниями по основным принципам обработки данных, знает досконально все объекты своего направления - перестать стрелять из пушки по воробьям и постараться более полноценно использовать свои знания и умения, а не применять их на превращение разработчика в кодера!

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

Ну тут уж вопрос только в ресурсах.
Если не читает sap01 - то можно отправлять на курсы уровня ac010.
"смежников" (mm/sd... co/pp... fi/co ) - обязательно на нормальные курсы по хорошему обзору функциональности.
А при ограниченности состава проектной команды - можно и на "настроечные" курсы: mm/sd действительно не плохо подменяют друг друга, если нет возможности сделать по 2 человека на модуль.

А разработчиков - сильно пытать не нужно! им sap01 хватит для понимания основных принципов функционирования системы.

Вот в том то и проблема , что смежники не прошли нормальные курсы ... я об этом с самого начала писала.
Ничего ... сейчас самостоятельно нагоняем.

Этот курс он слушал Выше я почему то забыл о курсе sap01.
Но вот честно, особенно большой разницы я не вижу.
Хотя в плане взаимодействия консультант-программист я с вами конечно согласен. Если времени на подробное ТЗ нет, то в принципе все вопросы решаются совместным обсуждением. Хотя здесь вопрос не только в том, что нужно "разжевать" разработчику, вопрос еще в документации.

Но вот что еще хочу понять:

Какого уровня понимания должно быть ТЗ? Там не должно быть таблиц и полей? Или о чем вы говорите?


А в этом моменте мне кажется разработчик сам должен понимать, что если это отчет, а не какая-нибудь выходная форма, то код должен быть настолько оптимизированным, чтобы выполнялся максимально быстро. И я как консультант не должен ему об этом напоминать, или я не прав? Я не могу контролировать качество его кода.

В принципе, наверно, достаточно будет ответить на эти вопросы и можно будет подвести итог по подготовке проектной команды к внедрению