Существуют ли недостатки у Axapta

[ppson]

Цитата:

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

1) производительность
Нормальная.
2) функциональность.
Общирная.
3) техническех требования
Минимальны.

Георгий, Аксапта - идеальная система ?

[Vadim Korepin]

Цитата:

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

Георгий, Аксапта - идеальная система ?

Георгий, ответь ДА! мне не поверят как заинтересованному лицу, а тебе вот точно поверят

[George Nordic]

Докажите обратное!



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

[ppson]

Цитата:

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

Докажите обратное!

Попытаюсь :-)
1) Производительность
Если в 1С была проблема что 20 человек не смогут одновременно провести накладные, то в Аксапте вас ждет "высокопроизводительное" закрытие склада по средней.
"По мелочи" набереться куча других замечаний по производительности.

2) Функциональность
Средняя.
Развитие фукнциональности за последние года два скорее отрицательное чем положительное (если исключить что местный МБС продолжает медленно поддерживать наши бухгалтерские плюшки)

3) Техтребования
Не комментирую.

4) и, наконец, удобства.
Какие?
Эргономические? Микрософт активно добавляет всякие вкусности в интерфейс 4ки.

[kvan]

Цитата:

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

1) Производительность
Если в 1С была проблема что 20 человек не смогут одновременно провести накладные, то в Аксапте вас ждет "высокопроизводительное" закрытие склада по средней.

А может сравнивать будем все таки с проведением накладных?

[ppson]

Цитата:

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

А может сравнивать будем все таки с проведением накладных?

Ситуация у клиентам - при запуске автоматического совоставления по клиентам блокировались заказы клиентов "насмерть".
Функционал стандартный.

Цитата:

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

Не потому ли что для 1С нужно мощное клиентское место а для Axapta в большинстве случаев нет?

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

Кван, не ловите меня на слове. У меня к этой системе положительное отношение, которое сформировалось на основе сравнения её с другими системами. Дружу с аксаптой уже 4й год, и пока не планирую изменять этой дружбе.
Аксапта не идеал, у неё есть очень много достоинств как и проблем.
Скорость закрытия склада по средней осталась такой же медленной, книги покупок/продаж формируются очень долго.

[Guest_UserId]

Для меня самое неудобное, при дописывание системы, было то что склады (места хранения) находятся в двух таблицах - "inventDim" и "inventLocation". Т.е зная InventLocationID какого-то скалада и ItemID номенклатуры нельзя сразу узнать остаток по этой номеклатуре из таблицы "inventSum", а приходится сначало лезть в таб. inventDim и по InventLocationID узнавать InventDimID этого склада. Для этого нужно писать более сложные запросы, которые дольше работают!!!!!!, добавлять лишние датасорсы на формы и т.д. В 1с помоему этого нет.
Ваще в базе данных там куча таблиц и полей у таблиц, которые нах никому не нужны.
Из-за этого все тормозит.
И еще ЖУТКО не удобный дизайн отчетов и форм.

P.S. А дописывать систему вам придется и много!!!

[kvan]

Цитата:

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

3) Техтребования
Не комментирую.

Не потому ли что для 1С нужно мощное клиентское место а для Axapta в большинстве случаев нет?

[perestoronin]

Не знаю поверите ли мне, но к сожалению, лучше Аксапты сейчас нет системы.
И как не было бы грустно, альтернативы пока нет.

Да, это дорогая система, стоимость лицензий может перевалить за 500тыс. Но у MS все дорого.

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

PS. 1) Лучше разработать собственную систему, но для этого конечные пользователи должны хорошо знать чего они хотят (а сейчас они хотят, чтобы компьютер все делал за них, и как он это будет делать, они считают, что это не их компетенция).
2) Конечно у Аксапты есть существенные проблемы (более важные чем удобство, функциональность, требования к оборудованию, производительность и даже надежность), но о них, как лицо заинтересованное я промолчу. У других систем дела не лучше

[George Nordic]

Цитата:

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

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

Да, в некоторых случаях - согласен. Вот, ребята разработали свою систему для авиапрома:http://erpforum.ru/forum/display_message.asp?mid=29588
А в общем случае - нет. Читайте: http://akop.ru/personal/1307?PARENT_RUBR=akop_art_it

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

P.S. Вы других систем не видели Нету идеальной системы. В Аксапте еще хоть что-то самому поправить можно

[perestoronin]

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

PS. По поводу создания своих компиляторов, СУБД и других сложных программых систем, замечу, что наметился переход, даже в MS, от технологии OOD в сторону нового веяния AOD. Поэтому я и сделал заключение о том, что лучше создавать в любом случае свою систему, конечно же если нет готовой , пусть даже и дорогой, т.к. упущенная выгода может оказаться существенно больше нескольких млн.евро.

[mazzy]

Цитата:

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

Не знаю поверите ли мне, но к сожалению, лучше Аксапты сейчас нет системы.
И как не было бы грустно, альтернативы пока нет.

Да, это дорогая система, стоимость лицензий может перевалить за 500тыс. Но у MS все дорого.

Да, Аксапта отличная система.

Не согласен насчет цены. Поищите. Тезис дороговизны возникает не в первых раз.
Я уже говорил: ВСЕ МОДУЛИ + 100 пользователей = 450тыс.
ВСЕ МОДУЛИ еще никем не покупались. Даже во всем мире, насколько я знаю.
В среднем, для оценки стоимости хорошо работает формула 2000 * кол-во одновременно работающих пользователей.
Подробно здесь http://www.rabota-na-rezultat.ru/erp/prices.html

По поводу быстродействия - нормальное.
В стандартной Аксапте, пользователи начинают хоть как-то приставать с быстродействием, если их одновременно входит больше 50-70. В сильно переписанной системе быстродействие может быть любым. Опыт повышения быстродействия у заказчиков говорит, что проблема проявляются как раз не с закрытием склада... А с самонаписанным функционалом. Смотрите например на проблемы Guest_UserId в этой ветке... Еще последний пример, http://forum.mazzy.ru/index.php?showtopic=4448&hl= Можно привести еще массу примеров...

macklakov, а ты все-таки почитай отчет. Там уже написан ответ на твои возражения.

Главный недостаток Аксапты на сегодняшний момент, на мой взгляд, катастрофический недостаток документации и методических материалов. Из-за этого народ тратит кучу сил и времени на разбор стандартного функционала. Из-за этого народ принимает неправильные решения, которые выливаются в низкую производительность, в неудобную работу с Аксаптой. Из-за этого народ неправильно использует стандартный функционал.

Нужна дока. Дока нужна прежде всего на стандартные API. Особенно на русские стандартные API.

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

[macklakov]

Цитата:

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

macklakov, а ты все-таки почитай отчет. Там уже написан ответ на твои возражения.

На всякий случай еще раз перечитал. Не обнаружил ответа.

Цитата:

Наполнение базы данных производилось путем запуска большого количества сценариев по обработке закупок, заказов, складских журналов и журналов Главной книги

Т.е. в момент тестирования происходила только разноска. Совершенно не учитывалось взаимодействие различных модулей.

Цитата:

В процедуре генерации данных использовался коэффициент 10 для всех тестируемых модулей: 10000 клиентов (стандартно 1000), 5000 наименований номенклатуры (стандартно 500) и т.д.
Среднее количество обрабатываемых строк в заказе – 10

Для реальной базы это не объем, т.к. есть тенденция накопления исторических данных, не говоря уже о транзакционных таблицах. А ведь "перегреваются" именно транзакционные таблицы, т.к. они быстро разрастаются, и используются из нескольких модулей одновременно, а иногда и внешними приложениями.
P.S. Вообще эта статья не заслуживает обсуждения, в данной ветке т.к. это "сферический конь в вакууме"

[Serge Kotov]

Цитата:

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

... Совершенно не учитывалось взаимодействие различных модулей ...
... Для реальной базы это не объем, т.к. есть тенденция накопления исторических данных, не говоря уже о транзакционных таблицах. А ведь "перегреваются" именно транзакционные таблицы, т.к. они быстро разрастаются, и используются из нескольких модулей одновременно, а иногда и внешними приложениями.
P.S. Вообще эта статья не заслуживает обсуждения, в данной ветке т.к. это "сферический конь в вакууме"

Тесты очень мощная штука если уметь видеть внутренние связи и уметь их интерпретировать на практике. Поэтому хорошо подготовленные и корректные тесты очень часто опровергают досужие вымыслы и суждения, которых многовато даже на очень профессиональном axforum. Уже вполне можно делать раздел "мифы и правда об Axapta".

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

Должен признаться, результаты теста меня тогда удивили, потому сильно модифицированная конфигурация и, мягко говоря, немалый объем БД (~160 GB) в условиях промышленной эксплуатации в сущности работали также как стандартная Axapta на 15 GB базе в этом тесте! Разумеется, если нагрузку интерпретировать в ASU и сопоставить с нагрузкой железной части. Иначе говоря, нарастив мощности серверов приложений до тех, которые использовались в тесте и при внезапном росте количества транзакций, мы бы получили результаты одного порядка с тестом.

Да, конечно, на нашей системе в реальности было бы трудно получить 50 тыс. строк заказов в час, но порядка 30 тыс. с учетом множества других пользователей, занятых своими задачами, а не вводом заказов - вполне.

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

[macklakov]

Цитата:

Сообщение от Serge Kotov

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

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

[mazzy]

Цитата:

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

На всякий случай еще раз перечитал. Не обнаружил ответа.

macklakov, Serge kotov, предлагаю обсуждение тестов вести в ветке обсуждения статьи
http://forum.mazzy.ru/index.php?showtopic=3497

Здесь, похоже, идет рубилово за добро.
Мы вряд ли сможем поговорить толково и с расстановкой о тестировании в этой ветке.

готов ответить там.

[perestoronin]

Цитата:

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

Не согласен насчет цены. Поищите. Тезис дороговизны возникает не в первых раз.
Я уже говорил: ВСЕ МОДУЛИ + 100 пользователей = 450тыс.

Но многие руководители предприятий на далекой периферии с такими ценами не соглашаются, даже имея хороший чистый доход. MS свои продукты в России (Москва - это не вся Россия, а только капля в море, если сравнивать территорию) могла бы раз в 10-30 подешевле продавать (только в России) (это был бы еще один большой маркетинговый шаг для захвата всего рынка ПО в России).
PS. Во всем мире доход у любых работающих компаний выше, чем у аналогичных в России как минимум в 10 раз.

Цитата:

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

По поводу быстродействия - нормальное.

На счет стандартного функционала - то тормозливость пропала только с выходом Axapta 3.0SP3 (про SP4 ничего сказать не смогу). Во всех предыдущих версиях из-за легкоустранимых ошибок (но почему-то MS устранять их не спешила )тормозливость операций пересчета и закрытия была заметна даже при одном работающем пользователе.

Цитата:

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

Главный недостаток Аксапты на сегодняшний момент, на мой взгляд, катастрофический недостаток документации и методических материалов.

Полностью согласен. Но весомый довод "внедренцев" и "программеров" - исходный код - это и есть Вам документация. Но мне такая документация не нужна.
Требуется хотя-бы поверхностное описание логики кода на всем понятном языке (от программиста до директора холдинга). К сожалению графический язык UML и некоторые другие более продвинутые технологии, для этого мало подходят, т.к. требует основательного обучения пользователей и не один день, и не намного нагляднее, чем исходный код, а описание логики на естественном языке, наводит на мысли о разночтении даже Библии разными конфессиями, просто диву даешься, как можно так извратить одни и те же простые слова, наверное нужен какой-то особый, Святой Дух, чтобы описания на естественном языке всеми воспринимались с одинаковым смыслом. Поэтому в софтверной индустрии вопрос о языке, графической нотации, всеми легко читаемым, остается открытым.

[2A]

Цитата:

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

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

Москва - далеко не капля в море.
1) Население: Москва+Московская область - 20 млн, т.е. ок. 14%.
2) ВВП: не меньше 20% от всей страны (можно уточнить).
3 )Многие компании имеют головной офис в Москве (и внедряют ERP часто там же),
тогда как основная деятельность - в других регионах.

[perestoronin]

Цитата:

Сообщение от 2A

Москва - далеко не капля в море.
1) Население: Москва+Московская область - 20 млн, т.е. ок. 14%.
тогда как основная деятельность - в других регионах.

Уточню, я имел ввиду территории. В Московской области (ее большей части) дела не лучше, чем в "других регионах"

[EVGL]

Отмечу такой небольшой недостаток: до версии SP4 получить правильную себестоимость производства и закрыть склад было практически нельзя. Даже в версии SP4 надо импортировать ряд хотфиксов. Может быть, теперь багов в расчете себестоимости в стандартной версии не осталось (в восточноевропейской точно есть!), но сомнения гложут.