|
06.03.2018, 10:45 | #1 |
Участник
|
И тишина Есть какой-то практический смысл из обсуждения? Или ничего нового, просто поболтали?
__________________
Ivanhoe as is.. |
|
06.03.2018, 11:00 | #2 |
Модератор
|
Цитата:
- "Trying to use unsupported country or region code RU, localized functionality for it is disabled" при переключении в "русскую" компанию перестало показываться? У меня в 7.3 - нет - "Планы разработки" для D365O уже начали публиковать? Я пока не встречал
__________________
-ТСЯ или -ТЬСЯ ? |
|
06.03.2018, 12:30 | #3 |
Banned
|
|
|
|
За это сообщение автора поблагодарили: Vadik (1). |
08.03.2018, 14:26 | #4 |
Banned
|
Цитата:
все плюсы выбора D365O, допустим, уже известны клиенту, так что здесь нужно лишь честно ответить, почему стоит или не стоит рассматривать AX 2012 R3
плюсы и минусы AX 2012 R3 прошу излагать исходя из интересов клиента, а не внедренца, вендора, продавца лицензий и т.п. клиент работает в российской юрисдикции и может запросто захотеть использовать российский локализаторский функционал Цитата:
Практический смысл для партнера по AX тоже можно найти. Не тратить в 2018 году ресурсы на D365O, а заниматься Microsoft CRM если нужна экспертиза по 365. D365O addresses none |
|
12.03.2018, 22:26 | #5 |
Участник
|
Ну раз все так очевидно, то..
Плюсы 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 сейчас (в любой стране) - это своего рода профессиональная трусость. |
|
14.03.2018, 00:41 | #6 |
Administrator
|
Как раз-таки из п.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 и предыдущим версиям - компании предпочитают минимизацию стоимости разработки, платя за это усложнением подъема и апгрейда.
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось Vadik; 14.03.2018 в 11:58. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (5), raz (5), AlGol (2). |
14.03.2018, 05:04 | #7 |
Участник
|
Цитата:
https://technet.microsoft.com/en-us/.../hh292604.aspx ) т.е. на практике это выглядит так(задача пусть та-же) -посылается запрос партнеру -прожект менеджер со стороны партнера ищет и выделяет консультанта, выделяет программиста -задача кодируется-тестируется, обновленная модель высылается клиенту -клиент выполняет установку модели на тестовое окружение(рекомендованная MS схема ниже, т.е. это минимум полдня работы человека IT), кроме этого на этом этапе могут возникнуть куча ошибок связанных с тем что версия АХ разработчика-партнера отличалась от вашей версии АХ(к примеру вы устанавливали какие-то фиксы от МС или решение другого партнера) -клиент выделяет пользователей для тестирования всего этого, хорошо если тестировать можно на любой базе, если нужны рабочие данные – это еще Procedure for initializing a staging environment from a production environment – несколько страниц описания -IT выделяет людей которые согласовывают остановку системы и в нерабочее время выполняют развертывание новой версии, пишут торжественное письмо как все круто обновилось Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее Последний раз редактировалось trud; 14.03.2018 в 05:19. |
|
|
За это сообщение автора поблагодарили: S.Kuskov (5), Vadik (1), raz (5), belugin (5), sukhanchik (10), AlGol (2). |
14.03.2018, 08:48 | #8 |
Злыдни
|
Мне вот интересно, какая часть модификаций соответствует приведенному выше "сферическому коню в вакууме", ну если не считать разработок отдельных модулей или "тяжелых" доработок, затрагивающих большое количество объектов и системных классов?
Я чаще сталкиваюсь с другой схемой: у клиента есть три окружения - dev, test и prod. На dev делают разработки, на test переносят проектом с отсечением лишнего из смежных доработок с помощью сравнения, а после тестирования, в зависимости от "пристрастий" клиента, перенос на prod проектом или моделью. Меня еще другой вопрос занимает: в D365 решили проблему с "пропаданием" добавленных в CU DeleteAction, если в таблице внесены изменения на не системных слоях?
__________________
люди...считают, что если техника не ломается, то ее не нужно ремонтировать. Инженеры считают, что если она не ломается, то нуждается в совершенствовании. |
|
14.03.2018, 09:57 | #9 |
Участник
|
Это зависит не от доработок, а от клиента. Следуя этой схеме моделстор можно накатить за 15 мин + синхронизация. Причем в идеале оттестировынный моделстор, что исключает ошибки сведения моделей или xpo. Некоторым клиентам плевать на даунтайм, хоть все выходные развлекайся, а некоторые работают 24/7 и готовы платить за зоопарк лишь бы не было простоя. Видимо вам такие не попадались.
|
|
|
За это сообщение автора поблагодарили: Vadik (1). |
14.03.2018, 18:23 | #10 |
Banned
|
Цитата:
Если взять 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 не означает совместимость, а означают невидимость несовместимости. И тут как раз по "правильной модели" каждое такое обновление - это новый проект тестирования совместимости каждые пол-года и соответственно увеличение стоимости каждой кастомизации каждые пол-года. |
|
04.04.2018, 11:45 | #11 |
Участник
|
Цитата:
Сообщение от 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. |
|
|
За это сообщение автора поблагодарили: sukhanchik (4), ax_mct (3). |
12.03.2018, 22:41 | #12 |
Участник
|
Такое ощущение, что вы в какой-то момент выпали из реальности и в вашей матрице затраты на разработку отсутствуют в принципе. Не говоря уже о прочих проблемах, которые обсуждались на форуме.
Особенно интересно в этом свете смотрится ваша рекомендация о том, что надо учиться правильно считать затраты, применять дисконтирование (!). Да какое там дисконтирование, если из рассмотрения выкинули самую затратную часть )) |
|
13.03.2018, 11:52 | #13 |
Участник
|
Сдается мне, "это был сарказм" (C)
|
|
|
За это сообщение автора поблагодарили: ax_mct (3). |
14.03.2018, 11:03 | #14 |
Модератор
|
sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать
Из лично Вашей практики - каковы были трудозатраты и длительность проектов по обновлению версий, накату сервис-паков, хотфиксов, расширенной функциональности распространяемой в фиде хотфиксов в 2012. Если были таковые, разумеется. Спасибо
__________________
-ТСЯ или -ТЬСЯ ? Последний раз редактировалось Vadik; 14.03.2018 в 12:01. |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
14.03.2018, 11:24 | #15 |
Участник
|
Цитата:
Сообщение от Vadik
sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать
для администраторов и модераторов внизу сообщения доступна ссылка "Последний раз редактировалось..." там открываются все версии сообщения, записанные в базу данных. сообщение можно восстановить. не ошибается только тот, кто ничего не делает. |
|
|
За это сообщение автора поблагодарили: Vadik (1), belugin (5). |
15.03.2018, 22:55 | #16 |
Administrator
|
Прошу прощения, что пропал - не было возможности ответить по существу.
Цитата:
Сообщение от trud
Что-то мне кажется вы сделали допущение что у вас в данный момент есть кто-то кто знает как это делать плюс свободен, кроме того опустили момент развертывания
... Ну т.е. в этом модели работы время программиста вообще ничтожно, будет там полчаса или 4. Если сравнить в этом ключе, то возможно D365 будет более прозрачна и быстрее Во-вторых это допущение применимо как только заказчик захочет иметь своего человечка для разработки и этому человечку дадут команду "сделать", т.е. он обучится как это делать, плюс будет свободен (ему выделят время), плюс он будет заниматься развертыванием (по крайней мере контролировать процесс). В-третьих из представленной схемы с партнером никак не следует, чем все-таки работа с D365 отличается от работы с AX2012. Наличие облака совершенно не связано с тем, что клиент не захочет контролировать содержимое обновления и не попросит присылать ему модели. Локальная установка системы совершенно не связана с тем, что клиенту обязательно нужно контролировать содержимое обновления и он не может дать доступ партнеру на свой терминальный сервер для проведения обновления. Цитата:
Сообщение от Vadik
sukhanchik, тысяча извинений - отредактировал Ваше сообщение вместо того чтобы процитировать
Цитата:
В маленьких базах (15 пользователей) весь подъем вообще можно сделать за человеко-месяц (из опыта). В больших базах (больше 100 пользователей) только подготовка данных может занять 3 месяца работы нескольких человек (также из опыта) Все вышеперечисленное относится к подъему на один или два сервис-пака (т.е. нечто глобальное) Однако, тут надо сделать одну очень существенную оговорку. Объективно нет смысла обновляться, если в новой версии нет нового функционала, ради которого происходит обновление. За исключением, когда обновляться заставляют технические причины (к примеру, Windows 10 не поддерживает приложения, написанные для DOS )) А если обновление производится ради функционала, то этот функционал нужно внедрить и, вполне вероятно, сделать пересмотр использование существующего функционала (давно-давно у меня была ситуация, когда я программировал функциональность на 4.0, которая впоследствии в очень сильно похожем варианте появилась в AX2009 в виде причин возврата в заказах на возврат. В этом случае нужно было бы выбросить мое "творение" и подкорректировать стандарт, если бы он не подошел напрямую). Т.о. по сути глобальное обновление должно сопровождаться мини-внедрением, а это уже целый проект и как ты не крути, программируя с прошлой версией и заботясь о будущем апгрейде, но перевнедрение превратит прошлую версию всего-лишь в систему-источник информации, какой является 1С или какая другая система, когда на предприятие приходит AX / D365. И перетягивание информации из одной системы в другую сведется к написанию таких же классов-загрузчиков данных в новой версии. Поэтому очень сложно корректно сравнить в общем случае потенциальные затраты на обновление системы с потенциальными затратами на перевнедрение. Если, к примеру, смотреть на АХ2012 - D365, то лично мое мнение, что здесь нужно делать именно перевнедрение, а не обновление. Т.е. усложнять разработку ради потенциального облегчения обновления конкретно на этой смене нет экономического смысла
__________________
Возможно сделать все. Вопрос времени Последний раз редактировалось sukhanchik; 16.03.2018 в 07:29. |
|
|
За это сообщение автора поблагодарили: Pustik (10). |
16.03.2018, 19:25 | #17 |
Участник
|
Я лично не накатывал на 12-ку крупные обновления, врать не буду. Но был случай накатывания, кажется, нового формата электронной декларации по НДС (KB3042242). Там изменений - с гулькин нос, но по зависимостям включено еще очень много чего. Так вот, судя по проектным записям, на установку обновления ушло что-то около 4 часов на нескольких разных средах, поскольку приложение дорабатывалось "по фен шую", с минимальным overlayering'ом. А потом еще около 25 часов ушло на разгребание ошибок, вылезших на рабочей системе в расчете сумм налогов по строкам заказов на продажу, чего от этого обновления никто не ожидал.
|
|
|
За это сообщение автора поблагодарили: sukhanchik (6). |
14.03.2018, 20:33 | #18 |
Участник
|
Согласен на 100%.
__________________
Ivanhoe as is.. |
|
16.03.2018, 09:52 | #19 |
Участник
|
По моему опыту самое сложно в 2012 было перевести с R2 на R3, и то это считалось в человеко-месяцах, даже не десятках. А накат промежуточных фиксов - обычная работа технической поддержки.
При этом по реальной практике переходы на R3 были скорее из любви к искусству (ну и облегчение наката локализационных фиксов), чем прям нужно для расширения функциональности. Все остальные переходы в моей практике AX 3.0 > AX 4.0, AX 4.0 > AX 2009, AX 4.0 > AX 2012 были реальными перевнедрениями. Работать с предыдущей версией конечно удобнее и в части сопоставления начальных данных, и подходов, даже какие-то куски кода можно взять. Но это все равно было перевнедрение. Почему должны измениться при D365 я не понимаю. Вот когда D365 станет совсем паблик облаком без выделенных инстансов - ну тогда и поговорим, но это совсем другой продукт будет.
__________________
Ivanhoe as is.. |
|
|
За это сообщение автора поблагодарили: sukhanchik (6). |
16.03.2018, 20:06 | #20 |
Участник
|
Можно я влезу, может не совсем с логичным вопросом, но все таки
А зачем вообще переходить на новую версию, если и так все достаточно неплохо работает. Попрошу оптимистов грязными тапками в меня не кидаться. Для меня 2009 -лучшая версия. Но есть то, что меня пугает. А не скажет ли Microsoft потом, когда то, что Windows новой версии, уже не будет поддерживать вашу Старую систему. А скажет : Вы обновитесь до новой и все у вас будет ок
__________________
-Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. |
|
Теги |
внедрение, как правильно |
|
|