Хотелось бы все-ж вернуться к теме топика и уйти от вопросов методолгии внедрения.
1. Западные системы: не сталкивался, но что-то мне говорит, что по вопросу поддержки законодательства РФ там может получится очень сильная головная боль, но наверняка не знаю, пинать ногами не надо
2. Российские системы:
Вот тут возникает вопрос, это какие-же из наших систем серийны в полном объеме? За несколько лет работы с различными "коробочными" системами на разных объектах, причем как со стороны внедренца от поставщиков, так и со стороны собственного предприятия НИ РАЗУ не видел, что-б окончательное внедрение прошло БЕЗ допрограммирования системы. Другое дело, что необходимость дописывать какой-нить функционал в рамках уже готовой системы значительно снижает трудозатраты на написание стандартных функций, общепринятых, таких как внесение платежей, ордеров и т.п., и поддрежку регламентируемых законодательством отчетных форм, более глубокой интеграции.
Насчет консультатнов, разговаривающих с руководством на одном языке
На этапе уговоров купить систему - это да, приходят грамотнейшие товарищи, а вот когда решение о ПНР принято, тогда все!
Внедренческие фирмы набирают стажеров, за гроши готовых мотаться по коммандировкам, ради опыта. И как раз вот тут то требуется человек от заказчика, который
а) Знает внедряемую систему и может оценить, как стажеры разложили БП, используют ли они свою систему так, как ее можно использовать.
б) Может переговорить с пользователем на его языке и донести/перевести это консультантам.
в) Не даст, не пропустит акт выполнения работ с чистой лажей, которую обычно и готовят, лишь бы отбить заплаченые деньги.
г) Просмотрит документацию, на предмет ее адекватности.
Не совсем постановщик, но уже где-то рядом
Поэтому, на мой взгляд, смысл закупки серийной системы - он есть, как минимум уменьшает работу собственной ИТ службы, а вот проведение ПНР силами сторонних внедренцев - сомнительное удовольствие, как правило внедрение проходит с тяжелым скрипом, и, как правило, требуют постепенно увеличивающейся доли привлечение своих служб, с последующим практически полным перехватом работ, когда внедренцев сажают лишь на написание инструкций. Если объем используемого от серийной системы функционала без переписки мал, пожалуй все-ж лучше организовать службу разработчиков у себя, а насчет постановки задачи - вот тут почему-б не привлечь консалтинговую фирму, пусть они и пишут ТЗ в соответсвии с гостами.

2Владимир11
авторНасчет инструкций - их ни кто(90% от пользователей) ни когда не читает и читать не будет, легче позвонить консультанту и спросить. Менталитет у нас такой. Другое дело пошаговые руководства, но они для дебилов.
Оригинально
Не поверите, комплект документов, необходимый для подтверждения окончания внедрения и используемый в ходе эксплуатации должен включать в себя как минимум:
1. Паспорт системы.
2. Регламент эксплуатации
3. Описание реализованых бизнес-процессов
4. Методологические инструкции.
5. Пользовательские инструкции на каждое рабочее место.
Насколько я понимаю, Вы пишите что пользователи не читают п.4, а п. 5 "для дебилов".
Методологические инструкции пишутся не для пользователей, а для методолгов, сопровождающих систему. Пользователи и не должны читать эти документы, а вот при появлении новых бизнес-процессов, в эти инструкции должны добавляться разделы.
Пользовательские инструкции, они и должны быть пошаговы, с "картинками",
расписывающие каждое действие пользователя. Только таким способом, Вы можете гарантировать, что особо "одаренный" или просто инициативный пользователь не найдет какую-нить возможность так "оптимизировать" свою работу, что потом все ИТ сопровождение неделю его действия разгребать и откатывать будет.

2mazzy
mazzyПомимо адреса и банка обычно есть параметры: условия оплаты, принадлежность к колонке прайс-листа, адреса доставки, склады по-умолчанию и т.п.
Ничего не путаем? Вообще-то авторусловия оплаты, принадлежность к колонке прайс-листа, адреса доставки, склады по-умолчанию это характеристика не контрагента, а контракта, договора.
Может я что-то не понимаю, буду признателен за комментарий.

mazzy
Несмотря на то, что в большинстве случаев договор существует только один.

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

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