Внедрение AX 2012 R3 в 2018-м году на новых российских проектах - за и против

[ax_mct]

Цитата:

Сообщение от trud

т.е. на практике это выглядит так(задача пусть та-же)
...
Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее

Не согласен. На практике пример 1 c лукапом будет идти как дополнительное пожелание и просто добавиться к чему-то большему. Никто в здравом уме не будет деплойить такое на PROD отдельно. То есть собственной процедуры деплоймента у подобных задач считай что нет.

Если взять AX2012 и AX2009 то затраты на деплоймент очень сравнимы. На моей текущем проекте AX2012 полное развертывание на PROD (5 серверов) занимает у меня 2 часа старым классическим способом через XPO (Это не значит что мы не умеем готовить модели, просто нет нужды). Да и с моделями затраты на деплоймент будут те же что и в AX2009.

Никакой непрозрачности нет, c AX2012 можно деплойить так же прозрачно и быстро как и с AX2009, AX2004.

Не хочешь XPO, а хочешь по модному как в D365O? Team Foundation Server в руки. Для D365O TFS обязателен, а для AX2012 опционален.

Коэффициент стоимости разработки 8 раз видется вполне реалистичным, то что как минимум 4 раза - не вызывает сомнений. Деплоймент же в D365O никак не может быть прозрачней и быстрей чем в AX2012. Так как единственно за счет чего это может быть - TFS, но он прекрасно предназначен и для AX2012.

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