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

[sukhanchik]

Цитата:

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

• решение о выборе версии системы должно быть принято, допустим, до конца марта 2018, так что D365O Spring 2018 release к тому времени выйти не успеет (я лично ставлю на конец мая-июнь )
• все плюсы выбора D365O, допустим, уже известны клиенту, так что здесь нужно лишь честно ответить, почему стоит или не стоит рассматривать AX 2012 R3
• плюсы и минусы AX 2012 R3 прошу излагать исходя из интересов клиента, а не внедренца, вендора, продавца лицензий и т.п.
• клиент работает в российской юрисдикции и может запросто захотеть использовать российский локализаторский функционал
• клиент всерьез рассматривает вариант запуска на своих серверах (в т.ч. D365O) и настороженно относится к Azure с учетом, скажем так, политических рисков
• высказываться прошу тех, кто на практике внедрял AX 2012 R2/R3 и при этом уже щупал D365O, а также читал ее планы развития и системные требования, а не просто смотрел рекламные ролики

Чувствую, что я внес некоторую сумятицу в благородном порыве внедрять D365
Тем не менее - аргументирую свое мнение по выбору версий с т.з. клиента
- В любой момент времени старая версия заведомо лучше, т.к. она уже обкатана. Если производитель (Микрософт в нашем случае) сможет гарантировать, что новая версия не хуже - все будут ставить всегда новую версию. Однако, если кто вспомнит процесс перехода с DOS на Windows или с Windows 98 на Windows 2000 или с XP на Vista - то всегда находились программы, которые были несовместимы с новой версией Windows. Т.о. я бы со стороны клиента, если бы мог отказаться от новой версии Windows - я бы отказался, т.к. плюсы новой версии не всегда очевидны, а минусы заметны невооруженным взглядом. Также, если считать с т.з. затрат, то:
- на освоение новой версии потратится время (=деньги)
- на методологию использования новых возможностей в новой версии потратится время (=деньги), т.к. какой смысл жить в парадигме старой версии, но с новой внешней оболочке
- на выявление подводных камней потратится время, причем это время самое непрогнозируемое и, как это обычно случается, потребуется потратить в самый неподходящий момент
Поэтому для меня (как для клиента) проще, когда есть человек-внедренец, обладающий знаниями по использованию версии Х, который может спланировать, поставить и внедрить эту версию для моего использования. При этом все подводные камни будут максимально спрогнозированы. Единственный (но существенный) недостаток такого подхода - я совершенно не учитываю мнение поставщика программы, который в общем-то может влиять на мое использование системы в будущем. Но тут надо понимать цель использования программы, т.к., к примеру, есть какие-нибудь датчики, у которых есть свое ПО и пользователю датчиков может быть совершенно не нужно обновлять это ПО (за исключением случаев, когда это вынуждают делать другие производители ПО - тот же Микрософт). И если не рассматривать вопрос использования АХ в роли бухгалтерско-налоговой программы, то вполне вероятно, что обновление ПО пользователю может и не требоваться (как минимум пользователю на этапе принятия решения о выборе программы - не всегда очевидно, зачем ему нужны обновления)

Цитата:

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

• решение о выборе версии системы должно быть принято, допустим, до конца марта 2018, так что D365O Spring 2018 release к тому времени выйти не успеет (я лично ставлю на конец мая-июнь )

- В D365FO есть ряд недоделок по сравнению с предыдущей версией, например, отсутствие оповещений. Соответственно, если моя цель использования системы требует устранения недоделки, то какой смысл брать версию в которой даже отсутствуют сроки по устранению недоделок? И это не просто отсутствие новой функциональности - это отсутствие старой, которая работала
- В D365FO серьезно усложняется процесс разработки и обслуживания рабочего приложения. Если мы предполагаем, что клиент про эти грабли знает, то он понимает, что в AX2012 достаточно установить 3 приложения дев-тест-прод для работы команды разработчиков. Максимум 4-е для страховки. В D365FO каждый разработчик обязан иметь свою виртуалку и кому-то (партнеру или самому разработчику) нужно озаботиться о хостинге разработческих виртуалок. Плюс интеграция между программным кодом. Запуск скриптов обновления на проде - требует в D365FO либо доп работ, либо наличие лишней студии на сервере. Синхронизация вышибает пользователей. Билд - не дает возможность работать.
- В D365FO усложнен процесс разработки - код не заработает если будет хотя бы одна ошибка компиляции. Форму быстро не причешешь - надо билдить. Да, в целом все это может и правильно в долгосрочной перспективе, но сильно усложняет процесс непосредственного внедрения. Т.е. это допрасходы на оплату допчасов разработчика (по сравнению с аналогичной работой в АХ2012)

Это просто примеры того, что D365FO сильнее бьет по карману заказчика по сравнению с АХ 2012, а плюсы использования именно D365FO клиенту не всегда очевидны, либо не всегда в его глазах стоят этих дополнительных денег

Цитата:

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

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

Ну тут все просто - этого функционала еще пока нет и с учетом сроков принятия решения (весна 2018) и сроков выхода локализации (вроде как конец 2018 - прошу меня поправить) просто смысла в D365, как в системе с российской локализацией - нет

Еще момент хочу отметить. В РФ на конец 2017 года (как мне рассказывали) было невозможно купить лицензии для пользователей иные, кроме как Team members (это Self-Service в 2012). Т.о. полноценно законно лицензироваться не получалось. Соответственно это еще один аргумент против D365FO.
Возможно на текущий момент чего-то поменялось - но я точно не знаю. В любом случае, если подобные проблемы есть - это играет не в пользу D365FO

Т.е. если учитывать эти аргументы, то АХ 2012R3 остается последней живой версией, с которой можно работать и терпеливо ждать, когда "причешут" D365FO

На практике - я сейчас участвую в проекте внедрения D365 в российской компании. В моем случае использование D365 (а не АХ2012) вполне оправдано в силу специфики требований заказчика, в т.ч. потому что не требуется (пока) российская локализация и в целом заказчик не настроен сильно модифицировать систему (т.о. мы обходимся без оверлеинга), однако вспоминая свои предыдущие проекты, на которых я участвовал - в условиях тех проектов (точнее с позиции тех заказчиков) я бы выбрал именно AX2012. Может конечно мир уже слишком изменился ...