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

[DAX.Company]

Цитата:

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

Хороший пример. Вспомните Валио в России и посмотрите, как изменился бизнес "всего лишь" из-за каких-то санкций.

Куда то не туда мы скатились в обсуждении

[Ace of Database]

У одного клиента даже пришлось переносить пакетные обработки на постоянно запущенный таймер в отдельном клиенте AX2012. И только потому, что пакетники требуют обновление CIL, а это в свою очередь требует остановки работы пользователей. А у этого клиента даже остановка длительностью в 1 час один раз в месяц - уже ЧП. Сразу всякие совещания собирают, выясняют как жить дальше. Из-за одного часа в месяц. Удалось довести систему до того, что она теперь работает месяцами без рестарта.
Представляю что будет в D365, где каждая доработка потребует остановки работы.
P.S. Я сам не против D365, особенно если за нее хорошо будут платить

[sukhanchik]

Цитата:

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

По поводу лицензий. sukhanchik не совсем прав, говоря, что продаётся только Team Member. Можно купить и "полного" пользователя - это аналог лицензии Enterprise. Но вот лицензия Activity (аналог Functional) в России пока что недоступна. И это действительно серьёзно ограничивает возможности продажи.
Второй момент - нельзя купить полные лицензии отдельно на Operations, только вместе со всеми остальными приложениями. Unified Operations Plan в России тоже недоступен.

Спасибо за поправку. Я детали не знал, только слышал, что есть сложности. Буду знать )

[trud]

Цитата:

Сообщение от DAX.Company

Что еще может придумать в этом плане Майкрософт? Как то сложно представить, что все вот так вдруг резко поменяется на кардинально другую платформу в ближайшие 10 лет.

ну кстати придумать то можно что-то легко(если есть бюджет ). например переписать все на C# в версии 9.0 под лозунгом что увеличится производительность(т.е. более того, это уже сделали в 7.3 для Electronic Reporting)
ну и да, хороший еще поинт про облака - D365 облачная в текущем виде не поддерживает 24*7, в 2012 это можно сделать

[Logger]

Цитата:

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

ну и да, хороший еще поинт про облака - D365 облачная в текущем виде не поддерживает 24*7, в 2012 это можно сделать

А в 2009-й еще легче можно сделать (в 12-й так просто по живой не накатишь изменения)

Ну вот почему у них всегда так ?

[gl00mie]

Цитата:

Начинать проект на 2012 это полгода-год разработки в старой системе. На 365 - это движение на острие прогресса.

Во-первых, кто мешает обойтись без разработки в 12-ке? Тем более, что в ней сейчас функционал ощутимо богаче, чем в 365-й. Во-вторых, про острие прогресса - вспоминается Артемий Лебедев:

Цитата:

Нет таких клиентов, которых е@#т, таблицами или дивами зах%$чен сайт. Нет таких клиентов, которых е@#т, хорошо ли пролилась пластмасса на третьем ребре жесткости. Нет таких клиентов, которых е@#т, что мы перерисовали черточки в "й" в шрифте, которым набрали книгу. Но всех клиентов е@#т, продался ли вагон их майонеза.

Цитата:

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

Минус AX2012 такой, что ни один вид разработки для нее невозможно будет обновить на текущую версию AX7: переделывать и переписывать придется ВСЕ.

Один мой коллега говорит, что ему проще воспринимать D365O как совершенно другую систему, лишь по случайности в чем-то похожую на AX2012, тогда переделки при подъеме функционала становятся логичными и понятными

Цитата:

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

Я для одного из моих прежних клиентов в январе оценил upgrade слоя. Получился проект в 1,5 лет для команды из 4-5 человек, или 1 800 000 долларов при швейцарских почасовых ставках, взятых по нижней границе. Как такое будете предлагать через пару лет?

Здесь рассматривается задача попроще: клиент новый, планов перехода с 12-ки на AX7 через полтора-два года у него 100% не будет. Потому что внедрение с нуля определенной версии Аксапты - это минимум лет на 5, из моего скромного опыта.

Цитата:

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

Скорее придется переходить на Акс8, а какие там ограничения будут, нам пока не известно.

К слову, AX8 (как минимум, платформу 8.0), если я ничего не путаю, обещают вроде уже этой весной

Цитата:

Сообщение от DAX.Company

Облака, LCS, Azure, extension, web, поддержка мобильных устройств, новый функционал, новый интерфейс, BI, Visual Studio. Плюс CRM добавили и прочие ватрушки.

См. выше про вагон майонеза.

Цитата:

Сообщение от DAX.Company

Или инопланетяне прилетят и ударят мощной магнитной бомбой. И все. Пропала информация о продажах йогуртов за прошлый квартал

Зря иронизируете. В больших компаниях простои стоят очень дорого - почитайте новости про KFC в Британии, как они меняли 3PL-провайдера и сколько им стоил каждый день в итоге. Или представьте крупную федеральную торговую сеть с ярко выраженной сезонностью бизнеса, у которой перед условной "черной пятницей" встал распределительный центр.

[Ivanhoe]

gloomie, а все таки, чтобы вернуть разговор в конструктив, ответьте на вопрос:

Цитата:

Чтобы что-то комментировать про 2012R3 нужно понимать, что же за плюсы выбрал себе клиент

в D365?

[Ivanhoe]

И тишина Есть какой-то практический смысл из обсуждения? Или ничего нового, просто поболтали?

[Vadik]

Цитата:

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

И тишина Есть какой-то практический смысл из обсуждения? Или ничего нового, просто поболтали?

Ну, обсуждать-то особо нечего пока..
- "Trying to use unsupported country or region code RU, localized functionality for it is disabled" при переключении в "русскую" компанию перестало показываться? У меня в 7.3 - нет
- "Планы разработки" для D365O уже начали публиковать? Я пока не встречал

[EVGL]

Цитата:

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

"Trying to use unsupported country or region code RU, localized functionality for it is disabled" при переключении в "русскую" компанию перестало показываться? У меня в 7.3 - нет

Для устранения предупреждения надо поменять настройку компании с "Address..." на "None".

[ax_mct]

Цитата:

все плюсы выбора D365O, допустим, уже известны клиенту, так что здесь нужно лишь честно ответить, почему стоит или не стоит рассматривать AX 2012 R3

плюсы и минусы AX 2012 R3 прошу излагать исходя из интересов клиента, а не внедренца, вендора, продавца лицензий и т.п.

клиент работает в российской юрисдикции и может запросто захотеть использовать российский локализаторский функционал

Цитата:

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

И тишина Есть какой-то практический смысл из обсуждения? Или ничего нового, просто поболтали?

Вывод очевиден что выбирать D365O не в интересах Российского клиента в 2018 году.

Практический смысл для партнера по AX тоже можно найти. Не тратить в 2018 году ресурсы на D365O, а заниматься Microsoft CRM если нужна экспертиза по 365.

D365O addresses none

[ap]

Ну раз все так очевидно, то..

Плюсы 365 (для клиента):

1) 365 - возможность купить по подписке, считайте ТСО, сравнивайте. Даже при продаже plan 2 - 365 выгоднее для клиента. Когда будет возможность купить только 365EE - будет еще выгоднее. Это будет очень скоро. Главное - научиться правильно считать ТСО (с учетом всех костов, ставки дисконтирования и т.д.) и правильно оптимизировать лицензии. (2012 в ажуре не предлагать - заоблачно дорого, как не вращай).
2) Ажур и все сервисы в нем
3) Новый подход к разработке - через экстеншены (да, это преимущество и очень серьезное).
4) Следствие из 1,2,3 - главное - принципиально другой time to market. Быстрая реакция бизнеса и ИТ на изменения. В разы.
5) Гибкость процессов (LCS, апп соурс, возможности самой платформы)
6) В среднем на 30-50% ниже начальные инвестиции в проект.
7) Срок полной поддержки 2012 - 3 года
8) Мгновенная неограниченная масштабируемость (частично входит в 2)
Список не финальный, но мне пора.

Кажого из этих пунктов в отдельности - достаточно, чтобы выбрать D365. Не только по отношению к 2012 и другим ERP системам на рынке.
Минусы: 1) нет локализации, но это временно и в целом уже тоже решено партнерами 2) слабая работа вендора в РФ, но так было всегда, с этим нужно смириться. Сам продукт - офигенен.

Вывод: продавать 2012 сейчас (в любой стране) - это своего рода профессиональная трусость.

[Logger]

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

Особенно интересно в этом свете смотрится ваша рекомендация о том, что надо учиться правильно считать затраты, применять дисконтирование (!). Да какое там дисконтирование, если из рассмотрения выкинули самую затратную часть ))

[Raven Melancholic]

Сдается мне, "это был сарказм" (C)

[ax_mct]

Цитата:

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

Рискну предположить, что клиент выбрал D365 потому, что это снизит в два раза (если допустиить, что стоимость лицензии 2012 +- равна стоимости консалтинга) или как минимум существенно первоначальные инвестиции в проект, поскольку 2012 нельзя купить по подписке.

Отчего бы в них не вдаться? )

А что, если клиенту локальная функциональность не особо нужна? Например, нужно только производство, склад и сводное планирование. Допустим, номер ГТД в фактуру можно вытащить через эктеншен. Рекомендации будут те же?

Цитата:

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

Вы исходите из того, что это нужно будет обязательно делать, но это не догма. Скорее придется переходить на Акс8, а какие там ограничения будут, нам пока не известно.

А может и не сарказм

[sukhanchik]

Как раз-таки из п.3 следует не быстрая, а медленная реакция ИТ на изменения. Экстеншены не могут ускорить разработку - они ее только замедляют, потому что решая вопрос "какие изменения внести" приходится дополнительно решать вопрос "как внести эти изменения".

Пример 1 (примеры приводятся технические, без привязки к бизнес-процессам и обсуждения, что идеологически этот пример не будет применен в жизни).
Заявка на закупку. Хочу в строках разрешить лукап номенклатуры (он изначально доступен только при создании строки, а я хочу ее выбирать и после создания строки). Но... на поле таблицы строк заявки стоит AllowEdit = No (AllowEditOnCreate=Yes).
Без экстеншенов достаточно было изменить только свойство на поле таблицы. (пример условный, предполагаем, что остальной код работает корректно). Ориентировочно, с учетом всех бюрократий (записать часы, внести изменения в багтрекер, задеплоить, протестировать и т.д.) будем считать, что это 0,5 часа.
С экстеншенами приходится делать edit-метод на гриде формы (т.е. делать экстеншн формы), плюс писать код по обработке этого edit-метода (lookup, modified, jumpref). Учитывая, что мы не можем влезать в код обработки этого поля, то нам нужно еще писать код, который бы запрещал / разрешал редактирование этого поля, например, когда запущен Workflow. Ну и если какая-то еще логика была на этом поле - ее также надо "перетянуть".
Т.о., с учетом всех бюрократий - на это можно потратить часа 4 (учтем, что с увеличением сложности разработки пропорционально увеличивается и время тестирования, т.о. усложнение разработки допустим в 2 раза увеличивает общее время решения задачи минимум раза в 4).

Цифры условные, если кто-то считает, что 4 - это много, то всяко думаю понятно, что эта работа сильно больше, чем просто поменять свойство на поле.

В моем случае соотношение получилось 1:8 - т.е. в 8 раз дольше занимает решение задачи через экстеншены по сравнению с оверлеингом.

Пример 2. Хочу добавить раскраску строк на форме. Пусть это бантик, но ... опять-таки в контексте гибкости изменений - это нормальное желание. Система технически не предоставляет возможности это сделать без оверлеинга либо дублирования формы. Дублирование формы чревато тем, что если к ней были сделаны экстеншены, то их нужно будет склеивать в нашу новую форму. Что влечет за собой дополнительные расходы. Ну и надо понимать, что дублирование формы предполагает встраивание ее в меню, во всякие иные вызовы и т.д. Опять-таки, при несложном критерии раскраски - с оверлеингом или своей формой задача решается за 0,5-1 час (со всей бюрократией). Дополнительные работы с учетом тестирования и прочей бюрократией опять могут дотянуть до 4-х часов.

Все вышесказанное не означает, что экстеншены плохие. У них есть самый главный плюс - их легко устанавливать в систему, если они готовые и корректно написаны. Корректно - это означает, что они не зависят от дополнительных экстеншенов, которые надо дополнительно устанавливать, либо все можно установить одним пакетом для данного конкретного клиента. В мире продаж - это корректно называть расширения / экстеншены, а в мире разработки они называются моделями.
Т.е. если к примеру представить себе, что вышло какое-то новое веяние - новое законодательство или новая мода (например, интеграция с соцсетями), то готовый корректный экстеншен можно загрузить из какого-нибудь магазина расширений и вуаля - "осталось" только его настроить.

Но в нашем неидеальном мире такое вряд ли будет в некотором обозримом будущем, поэтому клиенты сами стремятся внести изменения "под себя". Кто-то больше, кто-то меньше. Т.е. по сути - сами пытаются вести разработку. А разработка "легкоустанавливаемых" расширений как раз-таки сильно сложнее простого оверлеинга, как это было в предыдущих версиях.

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

[trud]

Цитата:

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

Пример 1
Заявка на закупку. Хочу в строках разрешить лукап номенклатуры

Что-то мне кажется вы сделали допущение что у вас в данный момент есть кто-то кто знает как это делать плюс свободен, кроме того опустили момент развертывания(который описан в документе Deploying Customizations Across Microsoft Dynamics AX 2012 Environments
https://technet.microsoft.com/en-us/.../hh292604.aspx )
т.е. на практике это выглядит так(задача пусть та-же)
-посылается запрос партнеру
-прожект менеджер со стороны партнера ищет и выделяет консультанта, выделяет программиста
-задача кодируется-тестируется, обновленная модель высылается клиенту
-клиент выполняет установку модели на тестовое окружение(рекомендованная MS схема ниже, т.е. это минимум полдня работы человека IT), кроме этого на этом этапе могут возникнуть куча ошибок связанных с тем что версия АХ разработчика-партнера отличалась от вашей версии АХ(к примеру вы устанавливали какие-то фиксы от МС или решение другого партнера)


-клиент выделяет пользователей для тестирования всего этого, хорошо если тестировать можно на любой базе, если нужны рабочие данные – это еще Procedure for initializing a staging environment from a production environment – несколько страниц описания
-IT выделяет людей которые согласовывают остановку системы и в нерабочее время выполняют развертывание новой версии, пишут торжественное письмо как все круто обновилось


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

[KiselevSA]

Цитата:

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

т.е. на практике это выглядит так(задача пусть та-же)

Мне вот интересно, какая часть модификаций соответствует приведенному выше "сферическому коню в вакууме", ну если не считать разработок отдельных модулей или "тяжелых" доработок, затрагивающих большое количество объектов и системных классов?
Я чаще сталкиваюсь с другой схемой: у клиента есть три окружения - dev, test и prod.
На dev делают разработки, на test переносят проектом с отсечением лишнего из смежных доработок с помощью сравнения, а после тестирования, в зависимости от "пристрастий" клиента, перенос на prod проектом или моделью.
Меня еще другой вопрос занимает: в D365 решили проблему с "пропаданием" добавленных в CU DeleteAction, если в таблице внесены изменения на не системных слоях?

[skuull]

Цитата:

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

Мне вот интересно, какая часть модификаций соответствует приведенному выше "сферическому коню в вакууме", ну если не считать разработок отдельных модулей или "тяжелых" доработок, затрагивающих большое количество объектов и системных классов?

Это зависит не от доработок, а от клиента. Следуя этой схеме моделстор можно накатить за 15 мин + синхронизация. Причем в идеале оттестировынный моделстор, что исключает ошибки сведения моделей или xpo. Некоторым клиентам плевать на даунтайм, хоть все выходные развлекайся, а некоторые работают 24/7 и готовы платить за зоопарк лишь бы не было простоя. Видимо вам такие не попадались.

[Vadik]

sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать

Из лично Вашей практики - каковы были трудозатраты и длительность проектов по обновлению версий, накату сервис-паков, хотфиксов, расширенной функциональности распространяемой в фиде хотфиксов в 2012. Если были таковые, разумеется. Спасибо