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

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

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

[Pavel]

Цитата:

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

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

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

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

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

[cuba]

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

[Morpheus]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

[George Nordic]

Цитата:

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

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

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

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

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

Георгий