Никакая это не теория, а жизнь. Есть те, кто ремонтирует квартиру годами и находят тому массу объяснений, а есть те, кто делают всю отделку за 3 месяца. Выбор каждый делает сам. Каждый год и в России и в мире успешно запускается масса проектов. И большинство успешных внедрений как раз комплексные.
Справедливости ради отмечу, что помодульное внедрение тоже имеет своё право на жизнь (ограниченное ), но надо понимать риски и управлять ими. Выбирая, что внедрить вначале, нужно исходить из того, чтобы в результате первого этапа получить что-то достаточно полезное. Если первый этап даст что-то сомнительной ценности для бизнеса, значит функциональность выбрана неправильно. Нужно понимать, что второй этап может начаться лет через N после первого.

А можно пример из российской практики?

http://www.sap.com/cis/industries/oil-g ... /index.epx
http://www.sap.com/cis/success/silovye_mash.pdf
Из того, что так или иначе встретилось лично на моём пути
Лукойл Румыния (внедрялось российскими консультантами)
ИБС внутренний проект
Лукойл ПНОС http://www.sap.com/cis/company/press/20 ... k_perm.epx
Сименс
Ефес
GM-Автоваз
ЛИТАСКО - внедрение в 10 странах за 10 месяцев MM/SD/FI/CO/IS-Oil, внедрялось российскими консультантами

Ссылки на sap.com неинтересно - это же маркетинг.
А про СМ - вообще не смешите меня. В курсе я про успешность внедрения там.

Говоря о российской практике, я имел в виду внедрения в российских компаниях, а Лукойл же там покупал...


Лукойл ПНОС внедрялось очередями, там же написано.
В ИБСе сначала внедрялся MM-SD-CO-FI-HR, для производственных компаний этого функционала явно мало.
Мои коллеги были на предприятиях Siemens в Германии, где им рассказали, что SAP там внедрялся около 10 лет... Возможно, это и не так... А российский точно внедрялся очередями. Вы опять вводите в заблуждение.

По Ефес и GM-Автоваз информации не имею, спорить не буду...
Насчет ЛИТАСКО спорить не буду (хотя причислять этот проект к российской практике, мне кажется некорректным, не только российские консультанты там участвовали... )

В общем, слабые аргументы.

Разбирать все Ваши аргументы не стану. Достаточно одного. Если внедрение MM-SD-CO-FI-HR в качестве первого этапа для Вас пример помодульного внедрения, то наверное мы спорим о чём-то разном. Аналогично и про очереди ПНОС - почитайте что в них входило.
К тому же я принципиально против того, чтобы перемывать косточки клиентам в форумах. Им это может не понравиться. Потому и сослался на официально опубликованные документы.

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

я ожидал примеров комплексных проектов, где делается сразу все.

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

А теперь я поясню, за что агитирую.
Насчет такого разделения я согласен. Но даже в этом случае проектирование должно осуществляться на систему в целом (на все очереди).
Иначе опять же появляется риск неинтегрированности, пусть не отдельных модулей, но очередей внедрения...

На все очереди вцелом можно только концептуально что-то предусмотреть. Для этого составляется довольно поверхностный документ - ИТ стратегия на N лет вперёд. Детально спроектировать нереально (в том понимании, как делается к примеру в строительстве - запроектировать можно целый квартал и детализировать всё до дверной ручки, а построить пока лишь трансформаторную будку) - для этого надо учесть требования представителей всех прочих подразделений, для этого надо их задействовать в процесс внедрения, обсуждения, в интеграционный тест, приёмку результатов и пр. Это уже будет означать, что они в рамках первой очереди. Так что надо понимать, что за рамками первой очереди у вас будет большая неопределённость и действительно в каждой последующей очереди придётся интегрироваться с уже имеющейся функциональностью. Но результатом каждой очереди должна быть целостная и полезная система.

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

Автоматизация сквозных БП - это и есть классический интегрированный подход. Тогда все подразделения изначально в рамках 1й очереди и мы сразу внедряем MM/PP/SD/FI/CO/..., т.к. сквозной процесс проходит через них всех. Всеми руками за! Если удастся поначалу упростить сквозные процессы, чтобы оборвать их, к примеру, перед SD, то SD можно пока отложить. Например, если сбыт у предприятия простой и не критичен.
А вот как вы будете учитывать мнение МТО, если внедряете один SD? Будете таскать снабженцев на все совещания, тесты, заставлять подписывать все документы?

Вот для этого и нужна детальная модель to be. На этом этапе обязательно участие всех.

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

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

А в какой момент по Вашему заканчивается проектирование? Со сдачей концептуального проекта?