Смысл перехода с 3.0 sp5 на 4.0 или 5.0

[gl00mie]

Цитата:

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

Самый главный аргумент - RecId.

Самый главный аргумент - выгрузка в Excel из любого места в системе!

Цитата:

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

Вот к примеру в 4.0 SP2 вышел сравнительно быстро после выхода российской локализации. После этого ничего не выходило особо сильно ценного. Если клиент не ведет бухгалтерский учет (потому как выпускавшиеся фиксы по локализации в основном не глобальные вещи меняли, а больше корректировали систему под требования законодательства РФ) - то ему эта поддержка ну никак не нужна позарез. А если еще и упор делается на складском учете - то уж точно острой необходимости нет. Да, был FeaturePack, были отдельные HotFix -ы, да, они конечно полезные... Но - стоят ли все они тех денег, которые требуется за поддержку?

Если посмотреть список того, что реализуется в плане локализации или находится в ближайших планах на реализацию, то там очень много вещей, которые "традиционно" дописывались самостоятельно; в этом плане переход на последнюю версию (причем не ту, что есть сейчас, а с учетом RU3 - где-нить весной-летом будущего года) в плане функционала интересен тем, что можно не тащить какие-то кастомизации, а поиметь очень многие нужные вещи в стандартном функционале, что дешевле и удобнее как в плане последующих обновлений, так и в плане обучения и работы пользователей, которым, к примеру, можно дать почитать чудо-двухтомних по функционалу вместо самописных инструкций. Опять же в ядре 2009-й появилось очень много вкусностей для разработчиков, которых не было в той же 4-ке, в результате чего ряд модификаций можно переписать более оптимально как по размеру и простоте кода, так и по скорости работы. И еще немаловажный момент - это переход на следующие версии. Чем новее текущая версия - как в плане ядра, так и в плане функционала, тем последующий переход проще и дешевле.

Цитата:

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

Если клиент обслуживается своими силами (и есть лицензия на разработку) - то рано или поздно критические ошибки будут исправлены. Если клиент обслуживается партнером (а ничто не мешает клиенту не платить в МС и платить партнеру) - то клиенту - вообще поддержка от МС может не сдаться. Потому что требуемые изменения от МС он запросто получит от партнера (имеется в виду - что партнер не будет ставить новый SP, а просто напишет аналогичный код - а результат будет такой же).

А если "критические ошибки" - в ядре, то партнер и их исправит?..

Цитата:

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

Причем это м.б. дешевле - т.к. SP, полученный от МС еще надо накатывать - а это не 5 и не 10 минут, особенно в модифицированном приложении. Т.е. стоимость обслуживания м.б. сопоставима со стоимостью "накатывания".

Зато чем новее версия ядра и приложения, тем меньше в приложении нужно модификаций (при нормальном использовании стандартного функционала) и тем проще и быстрее накатывать очередной SP

Цитата:

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

Единственный плюс который я вижу от поддержки - это бесплатная новая версия. Но и это вопрос спорный. Т.к. ставить AX2009, просто тупо перенеся туда изменения в коде 4.0 бессмысленно. А если пользоваться всеми "благами" - то фактически нужно перевнедрение - пусть и не такое какое было первоначально - но тем не менее

Разумеется, нужно в определенном смысле перевнедрение, чтобы задействовать новые возможности, но ведь и Аксапта - это не среда для разработки, раз уж купили ее, то надо брать от нее по максимуму. Опять-таки, с точки зрения поиска консультантов и разработчиков инетереснее иметь последнюю или предыдущую версию (и запланированный переход на последнюю ) чтобы, как уже упоминалось, не переплачивать специалистам за обслуживание старой версии, на которой банально не каждый еще согласится работать.

[BOAL]

Цитата:

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

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

Сильно сомневаюсь, что юзеры заработают по книжкам к АХ. Книжки полезны для аналитиков в Центре Компетенции Заказчика - это да, и то не факт, что все освоят.
А простым пользователям нужны простые инструкции.
Они не будут печатать себе 2К страниц и искать в них "а что касается меня".
Использовать книжки для написания своих инструкций - это другое.

К слову, переход со "своих фишек" на их аналог в стандарте == переобочуению юзеров + переписка инструкций (мини перевнедрение фишек фактически).
Если таких фишек много, как написал sukhanchik, будет равно перевнедрению (путь и ускоренному).

[sukhanchik]

Цитата:

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

то там очень много вещей, которые "традиционно" дописывались самостоятельно;

Согласен. При выборе новой системы - этот аргумент убедительный. А вот когда все пользователи отработали на "дописке" и ей обучены - то смысл менять шило на мыло просто так (а точнее заплатив за это) - отпадает.

Цитата:

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

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

Можно. Но зачем это клиенту ТАКОЙ ценой? Оптимизировать скорость выполнения можно и в старом коде с на порядок меньшими затратами

Цитата:

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

И еще немаловажный момент - это переход на следующие версии. Чем новее текущая версия - как в плане ядра, так и в плане функционала, тем последующий переход проще и дешевле.

Но при этом мы забываем про уже понесенные затраты на текущую версию.
Что лучше для пассажира - доехать на электричке из 1-й зоны в 20-ю или сначала из 1-й в 10-ю, а потом из 10-й в 20-ю?
Когда едешь с пересадками - больше прыгаешь и мучаешься. И главное - больше платишь.

Цитата:

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

А если "критические ошибки" - в ядре, то партнер и их исправит?..

Нет. Но и принципиальных "критических ошибок" в ядре практически не бывает (или они легко обходятся). Потому что ошибку в ядре либо видят все и работать не может никто, либо видят только некоторые. Ядро оно на то и ядро. Кстати - это очередной довод не менять ядро (не менять уже проверенное ядро на новое - "лучшее враг хорошего" (с))

Цитата:

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

Зато чем новее версия ядра и приложения, тем меньше в приложении нужно модификаций (при нормальном использовании стандартного функционала) и тем проще и быстрее накатывать очередной SP

Конечно. Вот только стоит цена вопроса этого SP. Если от SP нужна только 1/10-я часть, то стоит ли она годовой подписки? Может ее просто заказать как разработку партнеру? Дешевле может выйти.

Цитата:

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

Разумеется, нужно в определенном смысле перевнедрение, чтобы задействовать новые возможности, но ведь и Аксапта - это не среда для разработки, раз уж купили ее, то надо брать от нее по максимуму. Опять-таки, с точки зрения поиска консультантов и разработчиков инетереснее иметь последнюю или предыдущую версию (и запланированный переход на последнюю ) чтобы, как уже упоминалось, не переплачивать специалистам за обслуживание старой версии, на которой банально не каждый еще согласится работать.

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