Не все так просто, к сожалению.
Последнее время мне все больше и больше приходится сдвигаться в сторону agile (хоть оно мне вообще-то и не нравится).
И причины примерно те же, что и у Филиппа.

Попробую описать ситуацию более кратко и жестко:
делаются "системы изменяющие организацию".
То есть:
1. Система реализует новые бизнес-процессы из "основной группы".
1.а Эти бизнес-процессы являются ключевыми для организации-заказчика.
1.б Заказчик рассчитывает, что их введение даст ему существенные конкурентные преимущества => с большой вероятностью (по крайней мере в данной отрасли) они еще не применялись.

2. Эти бизнес-процессы существенно завязаны на создаваемую информационную систему.
2.а Как следствие, они зачастую не могут быть запущены заранее "на бумаге" (ниже — "психотренинг БП" полностью отделить от разработки ИС не удается, без нее он остается "теоретическим").

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


Здравствуйте, Gaperton, Вы писали:
G>Это реинжиниринг бизнес-процессов, который вообще-то лежит вне контекста автоматизации. Совершенно отдельная работа. Выполняется специально обученными консультантами, а не программистами.

Да. Но результат их работы не будет завершенным НИР, а будет только "теорией", пока бизнес-процессы не "запущены".
Хорошо, если их можно запустить без ИС, но так бывает не всегда.

G>А то я не сталкивался с этой проблемой — автоматизация во время реорганизации . Надо взять паузу, чтобы заказчик устаканил свои процессы. Разработку тормознуть, выделить заказчику аналитика. Какой смысл вести разработку постоянно переделывая?

В случае, если для "устаканивания процессов" требуется наличие ИС пауза не поможет.
Случай когда "эти два дерева могут рости только вместе".
Хотя кое в чем ты и прав — характерное время изменений в организации обычно заметно больше времени написания поддерживающего софта. Так что притормаживать порой надо.