Заказная разработка vs Стандартное приложение

[George Nordic]

***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. Да много еще плюсов

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

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

С Уважением,
Георгий

[Pavel]

Цитата:

Сообщение от George Nordic

Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: Чем Qlik похож на Axapta как раз и состояла в том, что я быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе. К тому же, "уже готовый модуль" писался под других клиентов, и там или все вшито в код, так что не исправишь, или куче ненужных мне настроек, которые нужны для "решения различных типов задач широкого круга клиентов"...

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

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

PS. или я что-то упустил, или это новый тренд, типа... 'антиотраслевые решения' или 'бизнес-процессы не помешают вашему бизнесу'.
Георгий, прости за небольшой стеб, настроение уже праздничное

[macklakov]

Цитата:

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

В итоге имеем заказную разработку, уникальную систему и жизненный цикл решения, привязанный исключительно к Васе

Ну, в своем-то кругу маркетинговые штампы использовать не обязательно
Традиционно AX имеет открытый код, а это значит, Петя довольно быстро разберется что там Вася понаписал. Даже если Вася не оставил документации.
И потом, настройка системы галочками отличается от ковыряния в коде лишь тем, что у консультанта гораздо меньше удобных инструментов, чем у программиста и меньше гибкости. Из-за этого консультантам приходится производить очень много документации которая, по сути, решает чисто технические задачи: перенос настроек между инстансами, контроль версий, комментарии. А т.к. консультант ограничен выбором существующего функционала, то зачастую этот функционал используется не по назначению.

[ax_mct]

Цитата:

Сообщение от George Nordic

Вот категорически несогласен. Основное преимущество DAX, о котором я упомянул здесь: как раз и состояла в том, что я быстрее бы новый модуль написал, чем разбирался бы в галочках уже готового модуля в другой системе.
...

То мое утверждение по минимизации программирования было вопросом по течению проектов на AX7.

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

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

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

[George Nordic]

Цитата:

Сообщение от 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С Бухгалтерия и на этой платформе пишется черт те чё, превращая ее в просто в самопал, который к бухгалтерии имеет столько же отношения как морская свинка к морю.

С Уважением,
Георгий

[cuba]

Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.

[Morpheus]

Цитата:

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

Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.

Серебряной пули нет

[Pavel]

Цитата:

Сообщение от George Nordic

Да так обычно и происходит, к сожалению. Я же специально вставил слово "правильно разработать". Кода ядро выполняет основные функции, а код его гармонично дополняет, следуя логике системы.

Ну, это же совсем другой смысл и другой тезис в дискуссии... ядро/основные функции/правильно разработать==кастомизировать - это обычное дело, спорить не с чем.

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

Для BI немного другая ситуация, там же нет цепочек добавленной стоимости, бизнес-процессов, информационного конвеера, формирующего в реальном режиме структурированный массив данных... для 'переработки существующих данных' (OLAP) Excel-подход вполне подходит.

[George Nordic]

Цитата:

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

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

А, не. Может, не совсем ясно выразился, я же писал "иногда". Точнее будет "иногда быстрее написать свой модуль для решения той или иной задачи, чем настраивать "универсальное" решение, перегруженное избыточной функциональностью". Ясно, что тот же WMS гораздо быстрее настроить, чем писать самому

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

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

Георгий

[ax_mct]

Цитата:

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

Господа, а я за изучение галочек, а не за программирование нового модуля. Нет, я конечно же понимаю, что велосипедостроение - это круто. Но зачем писать то что уже написано?!
Из версии в версию стандартный функционал все ширится и ширится. И то что когда-то программировалось успешно (или не очень успешно, то терпимо) вошло в последующие версии, Roll-up'ы или CU Аксапты.
Тенденция идет к тому, что на проектах все больше и больше задач решается консультантами путем настройки, а не девелоперством.

На стороне клиента все чаще сидят недураки которые не разбрасываются деньгами на попограммировать. Это скорее миф про жажду изобретения велосипедов в АХ. Чаще всего то что есть и как есть - не подходит, и у клиента есть выбор или менять бизнес-процессы или программировать. Мне ни разу не встречалось чтобы клиент менял бизнес-процессы.

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

Допускаю что есть проекты АХ без программирования, но меня в такие не приглашают И там где его нет то для меня вопрос зачем собственно тогда АХ выбрана.

[ax_mct]

Заказная разработка vs Стандартное приложение уместно до версии AX 2012 включительно.
Заказная разработка это решение и выбор клиента, не наш.
Свобода выбора у партнера если есть то только в части того что предложить на такой выбор.

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

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

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

[Diman]

Цитата:

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

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

Как мне кажется, тут нет особого выбора, либо ты как ISV идешь на площадку, либо ты вне игры.

Цитата:

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

А заказному программированию как мы его знаем - конец.

Ну сами решения тоже кто-то должен разрабатывать. Просто, в большинстве случаев это уже не конечный клиент, а ISV с доступом к маркету.
С маркетом для AX вот мне не понятно как будут уживаться решения от разных поставщиков внутри одной системы на конечном клиенте. Теперь получим лоскутную автоматизацию внутри системы?

[ax_mct]

Цитата:

Сообщение от 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 и чешут голову

[ax_mct]

Цитата:

Сообщение от 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
Даже интересно

[fed]

Цитата:

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

AppSource надо смотреть, а не Azure Marketplace
81 продукт от 28 партнеров
Dynamics 365 for operations
https://appsource.microsoft.com/en-u...for-operations
Даже интересно

То есть число продуктов почти в два раза больше чем число внедрений семерки Хорошо чуваки инвестировали, ничего не скажешь...