Здравствуйте, Alex EXO, Вы писали:

AE>Не все так просто, к сожалению.
Разумеется

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

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

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

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

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

Льете воду на мельницу ватерфола, Алекс .

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

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

Именно будет завершенным именно НИР. И одним из результатов НИР будет проект ТЗ и пожтапный план внедрения. Кстати, для большой организации практически всегда можно запускать автоматизацию потапно. Без исключений. Вы неправы, Алекс, утверждая, что надо реализовать обязательно полную функциональность. Просто этапы надо бить не по отделам и филиалам, а по "функциональным блокам". У меня плохо с памятью — но посмотрите стандарт (кажется) MRP2 — там дано такое разбиение.


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

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

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

Короче, Алекс, вы будете вероятно смеяться, но я абсолютно серьезен — в данной ситуации как раз показан жосткий ватерфол. По всем канонам. Agile приведет к провалу. Шляпу сожру, натурально. С точки зрения проектного управления — ситуация полностью — полностью аналогична проектам микроэлектроники.