Путано получается, надо проще! Да и название Лабораторные/Полевые - неправильное. Все же не Полевые а Боевые.
 
Лабораторные / Боевые
 
Ассоциативно может показаться, что боевые обязательно должны быть лучше, но чтобы лучше представить я уточную параллель.
 
Допустим бизнес – это пушка, а ERP система – это конвейер для быстрой подачи снарядов (по техническим причинам снаряды лежат не совсем рядом). В этом случае вид и форма боевого конвейера зависит от рельефа местности. Но обратите внимание, что для другой пушки тот же самый конвейер может не подойти. Если мы воюем на ровной поверхности, то всегда подойдет, но даже в той же отрасли новая компания находится на другом месте и там другой рельеф.
Боевой конвейер можно переместить к другой пушке, отпилив все лишнее и укрепив дополнительными подставками, однако есть шанс, что после того как мы отпилим все лишнее выясниться, что у этой самоделки нет каркаса и она не жизнеспособна.
Лабораторный конвейер, конечно разрабатывался на ровной местности, но его сразу пытались сделать таким, чтобы и в овраге при небольшой допилке, он бы смог работать. Конечно жизнь преподнесет нам совсем другой овраг, и все конструкция лабораторного решения имеет жесткий хребет и есть шанс заставить его работать в новой местности.
 
Второй вариант анологии – это вакцина. Бизнес – живое существо, болезнь – это человеческий фактор. Боевая вакцина конечно эффективна, но только для конкретного штамма вируса. Другая фирма – это другие особенности и люди используют их иначе в свою пользу. Это тоже человеческий фактор, но он имеет другие проявления – другой штамм. Боевую вакцину исправить сложно, вот новую лабораторную, которая сразу делалась для уничтожения различных вирусов натравить на новый вирус проще…

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

"Однако при прочих равных по накопленному опыту" - При прочих равных мы получаем тоже самое решение являющееся видением того самого взятого "опытного управленца, который долго управлял автосервисами", кстати а кто сказал что он хорошо знает как оно там все бегает, или так решили от того что он долго управлял? Что-то мне кажется полевое решение при прочих равных имеет больше шансов на успех, а потому что оно уже где-то работает и его можно показать, а вот лабораторная мышь... это таки лабораторная мышь и выпусти ее в поле и что? Сдохнет в первый же день, так как жизненные функции, читай применимость использования разработанной лабораторной системы, практически нулевые и их то как раз вы и будете допиливать уже в полевых условиях. Так что именно при прочих равных, я бы смотрел, как вы говорите на "полевые" отраслевые системы, а потому что а кто сказал, что "опытны управленец" не работает на том клиенте, где мы внедряем систему? Условия же вы сами сказали являются "прочими и равными" :-).

А как же народная мудрость? - "в своем глазу бревна не видно"! Стоит ли требовать полный перечень проблем от Заказчика?
Конечно, они знают ради чего запускают Проект (должны знать). Но все ж, рассчитывать на полный перечень проблем не стоит, да и в любом случае, перечень может и должен быть расширен совместными усилиями Заказчика и команды внедрения - ведь кроме не заметных изнутри проблем еще существует целый набор различных траблов, которые непосредственно проявляются при интеграции всех процессов в единую систему.
 
А по "бюджетненько" - специально взял в кавычки, поскольку, не сильно верю, что проекты внедряемые слабой командой (в т.ч. и с перегруженными разными задачами специалистами) выходят действительно бюджетными.
 
Проект СО - частности, но появление там такого архитектора, как Олег - немного повышает шансы проекта на успех!

Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

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

Как части мы видим до начала проекта перечень проблем бизнеса, которые должен решить проект внедрения?

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

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

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

Ваш опыт подвИг нас тоже на пОдвиг! :-) Извините за каламбур... Заканчиваем аналогичный внутренний собственный проект!

Хотел уточнить про отчетность - чем больше пользуется Ваши пользователи - Web Intellegence или Desktop Intellegence? Реализовывали ли отчеты в Crystal Reports? Я так понимаю для анализа результатов руководству больше нравится, наверное, дашборды Xcelsius? С Наступающим! :-) Успехов!

пользуются :-)

Хотел уточнить про отчетность - чем больше пользуется Ваши пользователи - Web Intellegence или Desktop Intellegence? Реализовывали ли отчеты в Crystal Reports? Я так понимаю для анализа результатов руководству больше нравится, наверное, дашборды Xcelsius? С Наступающим! :-) Успехов!