|
16.12.2016, 00:42 | #1 |
Модератор
|
Легче дорабатывать не трогая стандарт за счет расширений и улучшенного eventing-а. Легче разворачивать и деплоить за счет того что все среды - стандартные из шаблонов. Легче поддерживать и обновлять (LCS). Вот я например сейчас на форуме, а билд в клиентской UAT среде разворачивается. Сам. Один
Цитата:
лучше продается?
Цитата:
или меньше багов?
Цитата:
или восхищает функциональность?
Цитата:
Прям ломанутся сейчас заказчики. Особенно за "Сервисы обеспечения жизненного цикла"
Цитата:
Вот как продажи пойдут. Тогда присоединюсь к восторгу
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: mazzy (2), ice (2). |
16.12.2016, 01:24 | #2 |
Banned
|
https://www.microsoft.com/en-us/dynamics365/operations
Не сомневаюсь что у версии все будет для нее самой хорошо. Но какие бы не были продажи возникает вопрос в чей карман деньги. Есть ли программирование как часть внедрения? Потому как по идее программирование на самом внедрении должно стремиться к нулю, и программирование должно концентрироваться вокруг создания продуктов через Marketplace. То есть программист AX уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения. |
|
28.12.2016, 14:09 | #3 |
Модератор
|
Цитата:
Сообщение от ax_mct
Есть ли программирование как часть внедрения?
Потому как по идее программирование на самом внедрении должно стремиться к нулю, и программирование должно концентрироваться вокруг создания продуктов через Marketplace. То есть программист AX уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения. Т.е. самая сильная стороны DAX были - это: 1. Отличный интерфейс и методы разработки интерфейса (метки, авторазмещение элементов, многооконный интерфейс, Morphix) 2. Грамотная техническая реализация моделей данных (Расширяемые типы данных, Таблицы/Проводки, связь таблиц по relations, AOS и т.д.) 3. [почти]Однотипная реализация основных механизмов работы учетной системы, шаблоны и паттерны (FormLetter, RunBase и т.д.). Зная один модуль, можно было легко разобраться как работает другой. 4. Отличная среда разработки. Самая быстрая, что я видел, для построения учетных систем. Самодокументируемая (рефакторинг), хорошо читаемая. 5. Да еще и с отличным дебаггером, начиная с 3ки. обеспечение 6. Отличный механизм совмещения разработок - слои. 7. Да много еще плюсов Все это обеспечивало надежную базу, о которой не надо было заморачиваться - финансовые и складские проводки, приход / списание / резервирование / планирование и так далее, и давало возможности очень быстро разработать что-то свое на этой базе. При этом, если правильно разработать, то и другой бы разобрался, как это работает, и основных механизмов бы не повредило, и, возможно, даже апдейды бы легли новой версии, без большого напильника. И при этом клиент получал решение именно его задач, адаптированное под него. С Уважением, Георгий |
|
17.12.2016, 08:58 | #4 |
Moderator
|
Цитата:
При этом очень пугают попытки Микрософт как-то отрубить возможность перекрывать стандартный код и продавить партнеров все делать с помощью расширений. Да - была и есть проблема безумных партнеров, которые прогибаются под любые хотелки клиентов и используют Аксапту как средство разработки. Тем не менее, даже на хорошо управляемых внедрениях, с вменяемым клиентом и консультантами, часто приходится модифицировать стандартную функциональность. Просто проблема в том, что очень часто, клиенту проще взять на себя риски и косты затрудненного обновления, чем риск просто остановить нафих весь бизнес при попытке одномоментной смены бизнес-процессов. В конце концов - апгрейд не самоцель. Если система работает и потребности бизнеса покрывает, может оказаться дешевле аккуратненько бэкпортить микрософтовские фиксы по мере надобности. Ну и конечно Микрософт пытается решить эту проблему по принципу "нет глазок - нет мультиков". Это конечно проще чем реально контроллировать деятельность партнеров, собирать статистику доработок по проектам, обеспечивать нормальную систему фидбека в Microsoft Connect или развивать нормальный консалтинг (который вообще-то нужен в первую очередь для фидбека по продукту, а не как sales engine). Но только проблема в том, что все это создает коллосальное недоверие к MS со стороны клиентов и партнеров. И именно поэтому, спрос на D365 в Azure так мал. Никто не хочет идти в крепостные к барам из MS. Потому что хрен его знает, что еще эти инноваторы нам выколят или отрежут для удобства апгрейда на следующую версию.... |
|
|
За это сообщение автора поблагодарили: Dactil (1), AP-1055D (1). |
17.12.2016, 16:25 | #5 |
северный Будда
|
Цитата:
Сообщение от fed
Замечу, что только за счет расширений и улучшенного eventing можно делать только совсем простые доработки, которые и раньше на раз-два переносились с помощью upgrade wizard.
При этом очень пугают попытки Микрософт как-то отрубить возможность перекрывать стандартный код и продавить партнеров все делать с помощью расширений. Да - была и есть проблема безумных партнеров, которые прогибаются под любые хотелки клиентов и используют Аксапту как средство разработки. Тем не менее, даже на хорошо управляемых внедрениях, с вменяемым клиентом и консультантами, часто приходится модифицировать стандартную функциональность. и полбеды в том, что на стандартных объектах только расширения можно писать. беда в том, что сам стандартный код не рефакторили под это - его просто закрыли на изменение ровно в том виде, в каком оно было в AX2012. в результате возникают ситуации типа "добавил поле в расширение стандартной таблицы - нужно подправить логику на методах формы, отображающей таблицу - к методам доступа нет". И расширение тут не спасает никак. P.S. А вообще мне кажется странной сама логика такой трансформации. Ведь был же прекрасный механизм слоёв, стандартный код был полностью защищён от изменений.
__________________
С уважением, Вячеслав |
|
|
За это сообщение автора поблагодарили: AP-1055D (1). |