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

[mazzy]

Цитата:

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

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

без паники.

для администраторов и модераторов внизу сообщения доступна ссылка "Последний раз редактировалось..."
там открываются все версии сообщения, записанные в базу данных.

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

[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 не означает совместимость, а означают невидимость несовместимости. И тут как раз по "правильной модели" каждое такое обновление - это новый проект тестирования совместимости каждые пол-года и соответственно увеличение стоимости каждой кастомизации каждые пол-года.

[Ivanhoe]

Согласен на 100%.

[sukhanchik]

Прошу прощения, что пропал - не было возможности ответить по существу.

Цитата:

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

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

Во-первых я оставил за скобками бюрократию сознательно, потому что считаю, что любая бюрократия всегда может "съесть" любую разработку ("Сколько нужно программистов чтобы поменять лампочку?"). При наличии такой бюрократии - уже неважна система Все равно любое обновление будет идти "по процедуре".
Во-вторых это допущение применимо как только заказчик захочет иметь своего человечка для разработки и этому человечку дадут команду "сделать", т.е. он обучится как это делать, плюс будет свободен (ему выделят время), плюс он будет заниматься развертыванием (по крайней мере контролировать процесс).
В-третьих из представленной схемы с партнером никак не следует, чем все-таки работа с D365 отличается от работы с AX2012. Наличие облака совершенно не связано с тем, что клиент не захочет контролировать содержимое обновления и не попросит присылать ему модели. Локальная установка системы совершенно не связана с тем, что клиенту обязательно нужно контролировать содержимое обновления и он не может дать доступ партнеру на свой терминальный сервер для проведения обновления.

Цитата:

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

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

Это восстановимо, да и я не контролирую какие слова пропали

Цитата:

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

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

Тут я признаюсь честно - таких проектов именно на AX 2012 у меня не было. Я судил по проектам в АХ 2009, предполагая, что в 2012 процедура усложнилась пересборкой CILа, получением хотфиксов через LCS и нормализованной структуры данных. По AX 2009 обычно это 2-4 человеко-недели на подъем кода (в зависимости от количества пересечений и сложности тестирования; половина времени отнимает непосредственно подъем кода и половина - тестирование) и 1-2 человеко-месяцев на подготовку обновляющих скриптов, инструкции и тестовых прогонов (разброс сильно зависит от объема БД и количества обновляемых таблиц; я не рассматриваю классы ReleaseUpdate*, в роли держателей скриптов, т.к. они хорошо работают только для небольшого объема данных и повторяют свою работу в каждой компании, в то время как для некоторых скриптов можно сэкономить и запускать обновляющий скрипт всего один раз по всем компаниям)

В маленьких базах (15 пользователей) весь подъем вообще можно сделать за человеко-месяц (из опыта).
В больших базах (больше 100 пользователей) только подготовка данных может занять 3 месяца работы нескольких человек (также из опыта)
Все вышеперечисленное относится к подъему на один или два сервис-пака (т.е. нечто глобальное)

Однако, тут надо сделать одну очень существенную оговорку. Объективно нет смысла обновляться, если в новой версии нет нового функционала, ради которого происходит обновление. За исключением, когда обновляться заставляют технические причины (к примеру, Windows 10 не поддерживает приложения, написанные для DOS ))
А если обновление производится ради функционала, то этот функционал нужно внедрить и, вполне вероятно, сделать пересмотр использование существующего функционала (давно-давно у меня была ситуация, когда я программировал функциональность на 4.0, которая впоследствии в очень сильно похожем варианте появилась в AX2009 в виде причин возврата в заказах на возврат. В этом случае нужно было бы выбросить мое "творение" и подкорректировать стандарт, если бы он не подошел напрямую). Т.о. по сути глобальное обновление должно сопровождаться мини-внедрением, а это уже целый проект и как ты не крути, программируя с прошлой версией и заботясь о будущем апгрейде, но перевнедрение превратит прошлую версию всего-лишь в систему-источник информации, какой является 1С или какая другая система, когда на предприятие приходит AX / D365. И перетягивание информации из одной системы в другую сведется к написанию таких же классов-загрузчиков данных в новой версии.

Поэтому очень сложно корректно сравнить в общем случае потенциальные затраты на обновление системы с потенциальными затратами на перевнедрение. Если, к примеру, смотреть на АХ2012 - D365, то лично мое мнение, что здесь нужно делать именно перевнедрение, а не обновление. Т.е. усложнять разработку ради потенциального облегчения обновления конкретно на этой смене нет экономического смысла

[Ivanhoe]

По моему опыту самое сложно в 2012 было перевести с R2 на R3, и то это считалось в человеко-месяцах, даже не десятках. А накат промежуточных фиксов - обычная работа технической поддержки.

При этом по реальной практике переходы на R3 были скорее из любви к искусству (ну и облегчение наката локализационных фиксов), чем прям нужно для расширения функциональности.

Все остальные переходы в моей практике AX 3.0 > AX 4.0, AX 4.0 > AX 2009, AX 4.0 > AX 2012 были реальными перевнедрениями. Работать с предыдущей версией конечно удобнее и в части сопоставления начальных данных, и подходов, даже какие-то куски кода можно взять. Но это все равно было перевнедрение. Почему должны измениться при D365 я не понимаю. Вот когда D365 станет совсем паблик облаком без выделенных инстансов - ну тогда и поговорим, но это совсем другой продукт будет.

[gl00mie]

Цитата:

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

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

Я лично не накатывал на 12-ку крупные обновления, врать не буду. Но был случай накатывания, кажется, нового формата электронной декларации по НДС (KB3042242). Там изменений - с гулькин нос, но по зависимостям включено еще очень много чего. Так вот, судя по проектным записям, на установку обновления ушло что-то около 4 часов на нескольких разных средах, поскольку приложение дорабатывалось "по фен шую", с минимальным overlayering'ом. А потом еще около 25 часов ушло на разгребание ошибок, вылезших на рабочей системе в расчете сумм налогов по строкам заказов на продажу, чего от этого обновления никто не ожидал.

[Pustik]

Можно я влезу, может не совсем с логичным вопросом, но все таки
А зачем вообще переходить на новую версию, если и так все достаточно неплохо работает.
Попрошу оптимистов грязными тапками в меня не кидаться. Для меня 2009 -лучшая версия. Но есть то, что меня пугает. А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок

[ax_mct]

AX2012R3 CU9 -> CU10 -> CU11 не слышал проблем на текущих проектах, все накатывалось по сути тех-поддержкой.
Установочная программа мержит код и показывает зеленым в коде что было что стало. Конфликты же за счет оverlayering легко определяются тем же установщиком и визуальны для программиста.

Обновления типа CU для D365O при отсутствии оverlayering - даже не знаю как определять наличие конфликтов.

[skuull]

Цитата:

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

Можно я влезу, может не совсем с логичным вопросом, но все таки
А зачем вообще переходить на новую версию, если и так все достаточно неплохо работает.
Попрошу оптимистов грязными тапками в меня не кидаться. Для меня 2009 -лучшая версия. Но есть то, что меня пугает. А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок

Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?

[ax_mct]

Цитата:

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

По моему опыту самое сложно в 2012 было перевести с R2 на R3, и то это считалось в человеко-месяцах, даже не десятках. А накат промежуточных фиксов - обычная работа технической поддержки.

При этом по реальной практике переходы на R3 были скорее из любви к искусству (ну и облегчение наката локализационных фиксов), чем прям нужно для расширения функциональности.

Все остальные переходы в моей практике AX 3.0 > AX 4.0, AX 4.0 > AX 2009, AX 4.0 > AX 2012 были реальными перевнедрениями. Работать с предыдущей версией конечно удобнее и в части сопоставления начальных данных, и подходов, даже какие-то куски кода можно взять. Но это все равно было перевнедрение. Почему должны измениться при D365 я не понимаю. Вот когда D365 станет совсем паблик облаком без выделенных инстансов - ну тогда и поговорим, но это совсем другой продукт будет.

И хотфиксы и обновления функционала неизбежны во всех версиях D365O. Другое дело кто-то раньше кто-то позже но все равно неизбежно. On-premises это вид развертывания облака, концепции это не меняет.



Standard and targeted platform releases
https://docs.microsoft.com/en-us/dyn...eview-releases

Тут по ходу можно записаться в тестеры
https://aka.ms/CAAPNomination

Цитата:

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

Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?

GDPR - это очень хороший пример. Но одно дело предоставлять проекты/решения в доступ и другое дело накатывать неумолимо в виде "1..100, кто не убежал, я не виноват". Зачем к примеру RU клиентам вливание логики по автоматическому удалению записей клиентской базы или исторических данных если GDPR это директива EU? Ну и всякий там бразильский функционал и прочий мусор со всего мира.

Нужен ли типичному бизнесу сети российских магазинов или авто-дилеров все эти горы международного мусора в качестве неизбежных обновлений?

Если ту же AX2012 можно зафиксировать под ногу в качестве платформы разработки со всеми этими наваленными в SYS локализациями всех стран, то в D365O это все индийское, бразильское и итальянское будет обновляться и обновляться со стороны вендора в качестве платформы для обновлений. Очень необходимая вещь для автосалона в Питере.

Этот "One size fits all" это больше для мультикорпораций с офисами по всему миру и стандартными бизнес-процессами. Хотя тоже глупость на самом деле. Но хоть как-то подходит для такого бизнеса.

Ладно бы существовала версия D365O RU в качестве форка (независимой версии) и которую бы обновляло российское представительство или Российская компания. Но зачем автосалону в Питере GDPR?

[Pustik]

Цитата:

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

Тут даже не МС, прийдёт какой-нибудь GDPR, МС для 12ки и 7ки напилит что-то, а для 9ки нет и что вы будите делать ?

Да, и этого тоже надо опасаться, скорей всего это более правдоподобно. По сути все те, кто приобрел ERP систему сели на иглу.

[skuull]

Цитата:

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

Ладно бы существовала версия D365O RU в качестве форка (независимой версии) и которую бы обновляло российское представительство или Российская компания. Но зачем автосалону в Питере GDPR?

Тут ответ очевиден и его никто не скрывает. Слишком дорого иметь одну версию для россии вторую для бразилии, третью для китая, а кто-то ведет бизнес везде и поставит все 3. В итоге бедному МС поддерживать весь этот зоопарк, а так меньше бранчей - меньше мержить!

[oip]

Цитата:

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

А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок

Обязательно когда-нибудь скажет. Например, мы наткнулись на то, что Axapta 4.0 не поддерживает TLS 1.2, а у клиента по внутренним политикам он стал обязательным. Ну и MS ничем помочь уже не может - версия-то не поддерживается.

[ax_mct]

Цитата:

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

Тут ответ очевиден и его никто не скрывает. Слишком дорого иметь одну версию для россии вторую для бразилии, третью для китая, а кто-то ведет бизнес везде и поставит все 3. В итоге бедному МС поддерживать весь этот зоопарк, а так меньше бранчей - меньше мержить!

Цитата:

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

Обязательно когда-нибудь скажет. Например, мы наткнулись на то, что Axapta 4.0 не поддерживает TLS 1.2, а у клиента по внутренним политикам он стал обязательным. Ну и MS ничем помочь уже не может - версия-то не поддерживается.

Дорого желание заграбастать все в одни руки, при децентрализации и бранчах, делегировании локальным компаниям, MS мог бы получить больше. А так он теряет рынок в той же России так как нашему условному автодилеру в Питере не нужны обновления по директивам EU, а нужны свои локальные обновления. Вовремя и по делу.

Ожидать же их от МС вовремя при такой мировой централизации - неразумно.
И если с AX2012 добавить свое локальное - это одно, то с D365O - совсем другое.

Это я к тому что если у российской компании нет работающих подразделений под юрисдикцией других стран, то рассматривать D365O в качестве новой версии ERP или альтернативы AX2012 - глупо.

Или у нас на форуме есть монстры программирования в Российском MS которым кажется что все не так? 3-5 человек которые способны покрыть нужды автодилера в Питере по российской специфике?
Может я чего не так понимаю.

[bio_unit]

Цитата:

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

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

Вас услышали:
Platform Update 15: https://docs.microsoft.com/en-us/dyn...form-update-15

Ability to color grid rows without overlayering via FormDataSource OnDisplayOptionInitialize event
The ability to color grid rows without overlayering is now possible via the OnDisplayOptionInitialize event on FormDataSource.