AXForum  
Вернуться   AXForum > Рынок > Методология внедрения
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 28.12.2016, 14:09   #1  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
***GN - Выделено из темы 4 года Dynamics AX 2012 ***

Цитата:
Сообщение от ax_mct Посмотреть сообщение
Есть ли программирование как часть внедрения?
Потому как по идее программирование на самом внедрении должно стремиться к нулю, и программирование должно концентрироваться вокруг создания продуктов через Marketplace. То есть программист AX уже кодить на проекте не должен практически. Консультантская работа тоже должна претерпеть изменения.
Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: Чем Qlik похож на Axapta как раз и состояла в том, что я иногда быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе. К тому же, "уже готовый модуль" писался под других клиентов, и там или все вшито в код, так что не исправишь, или куче ненужных мне настроек, которые нужны для "решения различных типов задач широкого круга клиентов", но мне они ну вот совсем не нужны и сильно снижают скорость настройки, понимание системы и, зачастую, скорость его работы.

Т.е. самая сильная стороны DAX были - это:
1. Отличный интерфейс и методы разработки интерфейса (метки, авторазмещение элементов, многооконный интерфейс, Morphix)
2. Грамотная техническая реализация моделей данных (Расширяемые типы данных, Таблицы/Проводки, связь таблиц по relations, AOS и т.д.)
3. [почти]Однотипная реализация основных механизмов работы учетной системы, шаблоны и паттерны (FormLetter, RunBase и т.д.). Зная один модуль, можно было легко разобраться как работает другой.
4. Отличная среда разработки. Самая быстрая, что я видел, для построения учетных систем. Самодокументируемая (рефакторинг), хорошо читаемая.
5. Да еще и с отличным дебаггером, начиная с 3ки.
обеспечение
6. Отличный механизм совмещения разработок - слои.
7. Да много еще плюсов

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

И при этом клиент получал решение именно его задач, адаптированное под него.

С Уважением,
Георгий
Старый 28.12.2016, 20:52   #2  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Заказная разработка vs Стандартное приложение
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: Чем Qlik похож на Axapta как раз и состояла в том, что я быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе. К тому же, "уже готовый модуль" писался под других клиентов, и там или все вшито в код, так что не исправишь, или куче ненужных мне настроек, которые нужны для "решения различных типов задач широкого круга клиентов"...
Получается дело не в системе... не в языке программирования и не в среде... суть она в голове разработчика... и вряд ли какой-нибудь Вася объявит заказчику, что он хуже Пети или Андре.

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

PS. или я что-то упустил, или это новый тренд, типа... 'антиотраслевые решения' или 'бизнес-процессы не помешают вашему бизнесу'.
Георгий, прости за небольшой стеб, настроение уже праздничное
Старый 29.12.2016, 02:28   #3  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
2,129 / 916 (35) +++++++
Регистрация: 03.04.2002
Цитата:
Сообщение от Pavel Посмотреть сообщение
В итоге имеем заказную разработку, уникальную систему и жизненный цикл решения, привязанный исключительно к Васе
Ну, в своем-то кругу маркетинговые штампы использовать не обязательно
Традиционно AX имеет открытый код, а это значит, Петя довольно быстро разберется что там Вася понаписал. Даже если Вася не оставил документации.
И потом, настройка системы галочками отличается от ковыряния в коде лишь тем, что у консультанта гораздо меньше удобных инструментов, чем у программиста и меньше гибкости. Из-за этого консультантам приходится производить очень много документации которая, по сути, решает чисто технические задачи: перенос настроек между инстансами, контроль версий, комментарии. А т.к. консультант ограничен выбором существующего функционала, то зачастую этот функционал используется не по назначению.
__________________
Isn't it nice when things just work?
Старый 29.12.2016, 02:58   #4  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: как раз и состояла в том, что я быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе.
...
То мое утверждение по минимизации программирования было вопросом по течению проектов на AX7.

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

А вот с AX7/D365Ops мне кажется что конец программированию на проектах как мы его знали. Уж больно дорого во всех отношениях должно получаться.

Но есть надежда что в конце концов AX2012 станет веткой развития наравне с AX7.
Года два им должно хватить чтобы понять очевидное.

Последний раз редактировалось ax_mct; 29.12.2016 в 03:15. Причина: grammar
Старый 29.12.2016, 11:23   #5  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Pavel Посмотреть сообщение
В итоге имеем заказную разработку, уникальную систему и жизненный цикл решения, привязанный исключительно к Васе (упаси Господь 'снег в башка попадет'). Под одним названием (типа, решение для...) на самом деле будут скрываться разные сущности. PS. или я что-то упустил, или это новый тренд, типа... 'антиотраслевые решения' или 'бизнес-процессы не помешают вашему бизнесу'.
Георгий, прости за небольшой стеб, настроение уже праздничное
Да так обычно и происходит, к сожалению. Я же специально вставил слово "правильно разработать". Кода ядро выполняет основные функции, а код его гармонично дополняет, следуя логике системы.

Смотри, на примере Oracle - им пришлось OEBS на кусочки разобрать, переносить все на интергационную шину Oracle Fusion Middleware, через которую, например, CRM общается с закупками.

Или SAP - и так перегруженный, но архитекторам хватило ума не пихать туда еще Demand Planning / EWM (WMS) / SNP и тд.
Сделали отдельный модуль - SAP SCM APO, в нем куча дополнительной функциональности. Но как она работает? На примере EWM - она берет основные настройки из SAP (номенклатура / вес / габариты), все остальные настройки, характерны для WMS - карта склада, ячейки, маршруты комплектации - все хранится в отдельной системе. Из SAP приходит заказ на отгрузку, WMS дает задание на подбор и комплектацию заказа и обратно присылает статус - все отгружено. Модуль действует автономно, интеграция - через CIF (Core Infrastructure Framework). Гениально.

То же самое многие делали к DAX - использовали как основные справочники и механизмы разноски, и дополняли функциональностью. Вот про что я говорил. Тогда и обновления накатывать можно, и функциональность можно безболезненно наращивать, и доработки отчуждать. И в "партнерские решения 1С" не превращать, когда берется 1С Бухгалтерия и на этой платформе пишется черт те чё, превращая ее в просто в самопал, который к бухгалтерии имеет столько же отношения как морская свинка к морю.

С Уважением,
Георгий
За это сообщение автора поблагодарили: mazzy (2), Pavel (7).
Старый 29.12.2016, 11:25   #6  
cuba is offline
cuba
Участник
 
346 / 134 (5) +++++
Регистрация: 18.09.2014
Адрес: Kyiv
Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.
Старый 29.12.2016, 12:02   #7  
Morpheus is offline
Morpheus
Участник
Аватар для Morpheus
Соотечественники
 
602 / 164 (7) ++++++
Регистрация: 30.03.2005
Адрес: Київ-København-Düsseldorf
Цитата:
Сообщение от cuba Посмотреть сообщение
Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.
Серебряной пули нет
За это сообщение автора поблагодарили: mazzy (2).
Старый 29.12.2016, 13:09   #8  
Pavel is offline
Pavel
SAP
SAP
 
2,760 / 239 (13) ++++++
Регистрация: 14.12.2001
Адрес: Moscow
Цитата:
Сообщение от George Nordic Посмотреть сообщение
Да так обычно и происходит, к сожалению. Я же специально вставил слово "правильно разработать". Кода ядро выполняет основные функции, а код его гармонично дополняет, следуя логике системы.
Ну, это же совсем другой смысл и другой тезис в дискуссии... ядро/основные функции/правильно разработать==кастомизировать - это обычное дело, спорить не с чем.

А вот утверждение 'быстрее написать, чем разбираться в галочках' у меня вызывает сомнения. Как можно 'написать', не зная системы, бизнеса или специфики заказчика? С другой стороны, если знаешь систему, бизнес, отрасль, специфику... то как можно её не настроить? Галочки по-любому быстрее раставить/переставить, чем кодить.
Выглядит как отрицание самой системы - 'быстрее написать, чем разбираться'.

Для BI немного другая ситуация, там же нет цепочек добавленной стоимости, бизнес-процессов, информационного конвеера, формирующего в реальном режиме структурированный массив данных... для 'переработки существующих данных' (OLAP) Excel-подход вполне подходит.
Старый 29.12.2016, 13:17   #9  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Цитата:
Сообщение от Pavel Посмотреть сообщение
А вот утверждение 'быстрее написать, чем разбираться в галочках' у меня вызывает сомнения. Как можно 'написать', не зная системы, бизнеса или специфики заказчика? С другой стороны, если знаешь систему, бизнес, отрасль, специфику... то как можно её не настроить? Галочки по-любому быстрее раставить/переставить, чем кодить.
Выглядит как отрицание самой системы - 'быстрее написать, чем разбираться'
А, не. Может, не совсем ясно выразился, я же писал "иногда". Точнее будет "иногда быстрее написать свой модуль для решения той или иной задачи, чем настраивать "универсальное" решение, перегруженное избыточной функциональностью". Ясно, что тот же WMS гораздо быстрее настроить, чем писать самому

Прости что ввел в заблуждение, тогда твои ирония понятна - сам не сторонник велосипедов. Да, перечитал, дико смотрится, надо аккуратнее формулировать, как Маззи говорит

И тебя с Наступающим!

Георгий
За это сообщение автора поблагодарили: GBH (1).
Старый 29.12.2016, 22:18   #10  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от cuba Посмотреть сообщение
Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.
На стороне клиента все чаще сидят недураки которые не разбрасываются деньгами на попограммировать. Это скорее миф про жажду изобретения велосипедов в АХ. Чаще всего то что есть и как есть - не подходит, и у клиента есть выбор или менять бизнес-процессы или программировать. Мне ни разу не встречалось чтобы клиент менял бизнес-процессы.

"Сила в правде", а она в том что АХ всю дорогу выбиралась из-за её гибкости и эффективности разработки в ней. Как фактор отличающей её скажем от SAP.

Допускаю что есть проекты АХ без программирования, но меня в такие не приглашают И там где его нет то для меня вопрос зачем собственно тогда АХ выбрана.
Старый 30.12.2016, 02:54   #11  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Заказная разработка vs Стандартное приложение уместно до версии AX 2012 включительно.
Заказная разработка это решение и выбор клиента, не наш.
Свобода выбора у партнера если есть то только в части того что предложить на такой выбор.

А вот с "AX7" это третья опция, старая как мир но конечно революционная с MS.
Azure marketplace как основная продавливаемая опция.
P.S. Могу ошибаться так как может быть это только SaaS а не площадка встраиваемых решений. То есть это все то как я понимаю, но не факты.

То есть готовое решение от ISV как плагин из списка доступного. Это и не стандарт, и не заказ.
https://azure.microsoft.com/en-us/ma...rm=dynamics+ax
Я кстати затрудняюсь с тем по каким словам искать

И здесь уже выбор за ISV идти на эту торговую площадку или нет. И смею думать что именно наличие доступных уже готовых решений и будет определять популярность "AX 7" там где стандарт не устраивает. А заказному программированию как мы его знаем - конец.

Последний раз редактировалось ax_mct; 30.12.2016 в 03:05. Причина: P.S.
Старый 23.01.2017, 12:52   #12  
Diman is offline
Diman
Участник
Сотрудники Microsoft Dynamics
 
166 / 35 (2) +++
Регистрация: 27.06.2003
Адрес: Москва
Цитата:
Сообщение от ax_mct Посмотреть сообщение
И здесь уже выбор за ISV идти на эту торговую площадку или нет. И смею думать что именно наличие доступных уже готовых решений и будет определять популярность "AX 7" там где стандарт не устраивает.
Как мне кажется, тут нет особого выбора, либо ты как ISV идешь на площадку, либо ты вне игры.
Цитата:
Сообщение от ax_mct Посмотреть сообщение
А заказному программированию как мы его знаем - конец.
Ну сами решения тоже кто-то должен разрабатывать. Просто, в большинстве случаев это уже не конечный клиент, а ISV с доступом к маркету.
С маркетом для AX вот мне не понятно как будут уживаться решения от разных поставщиков внутри одной системы на конечном клиенте. Теперь получим лоскутную автоматизацию внутри системы?
__________________
Sapere aude
Старый 23.01.2017, 16:38   #13  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от Diman Посмотреть сообщение
Как мне кажется, тут нет особого выбора, либо ты как ISV идешь на площадку, либо ты вне игры.

Ну сами решения тоже кто-то должен разрабатывать. Просто, в большинстве случаев это уже не конечный клиент, а ISV с доступом к маркету.
С маркетом для AX вот мне не понятно как будут уживаться решения от разных поставщиков внутри одной системы на конечном клиенте. Теперь получим лоскутную автоматизацию внутри системы?
Основной mainstream разработки в AX7 - максимально все "сбоку" через extension framework когда все в основном через event handlers. То есть очень теоретически код двух решений с marketplace пересекаться между собой не должен. Но это со стороны пересечения на уровне кода, а не функциональной совместимости как результата работы кода.

Но это чисто страшилка, так как при возможности использовать extension framework везде и всюду в AX7 и при грамотной архитектуре этих расширений - боятся только те кто слишком хорошо знает систему

Этот третий вариант - готовые расширения на Azure Marketplace для D365 for Operations, где они ? сколько их? Год прошел с момента релиза.
https://azure.microsoft.com/en-us/marketplace/?term=AX
Вот какие ключевые слова надо использовать?

А ISV пока работают с AX 2012 и чешут голову
Старый 23.01.2017, 23:45   #14  
ax_mct is offline
ax_mct
Banned
 
2,548 / 1091 (0) ++++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от ax_mct Посмотреть сообщение
Этот третий вариант - готовые расширения на Azure Marketplace для D365 for Operations, где они ? сколько их? Год прошел с момента релиза.
https://azure.microsoft.com/en-us/marketplace/?term=AX
Вот какие ключевые слова надо использовать?
AppSource надо смотреть, а не Azure Marketplace
81 продукт от 28 партнеров
Dynamics 365 for operations
https://appsource.microsoft.com/en-u...for-operations
Даже интересно
Старый 24.01.2017, 09:20   #15  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от ax_mct Посмотреть сообщение
AppSource надо смотреть, а не Azure Marketplace
81 продукт от 28 партнеров
Dynamics 365 for operations
https://appsource.microsoft.com/en-u...for-operations
Даже интересно
То есть число продуктов почти в два раза больше чем число внедрений семерки Хорошо чуваки инвестировали, ничего не скажешь...
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Удаленная разработка в MS Dynamics AX DaxDevRemote Курилка 647 04.06.2017 23:17
Консалтингу не выгодна разработка mnt_dx Курилка 80 11.09.2012 22:00
Портрет участника 2011-2012: Как сильно модифицировано ваше приложение Аксапты? (в %, методика в первом сообщении) mazzy Информация для участников 1 27.02.2012 11:29
Портрет участника 2010: Как сильно модифицировано ваше приложение Аксапты? (в процентах) mazzy Информация для участников 3 26.11.2010 17:13
Портрет участника 2009: Как сильно модифицировано ваше приложение Аксапты? (в процентах) mazzy Информация для участников 4 09.11.2009 10:57
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:48.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.